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FOREWORD 


This  publication,  "Department  of  Defense  Trusted  Computer  System  Evaluation  Criteria," 
is  being  issued  by  the  DoD  Computer  Security  Center  under  the  authority  of  and  in 
accordance  with  DoD  Directive  5215.1,  "Computer  Security  Evaluation  Center."  The 
criteria  defined  in  this  document  constitute  a  uniform  set  of  basic  requirements  and 
evaluation  classes  for  assessing  the  effectiveness  of  security  controls  built  into  Automatic 
Data  Processing  (ADP)  systems.  These  criteria  are  intended  for  use  in  the  evaluation  and 
selection  of  ADP  systems  being  considered  for  the  processing  and/or  storage  and  retrieval  of 
sensitive  or  classified  information  by  the  Department  of  Defense.  Point  of  contact 
concerning  this  publication  is  the  Office  of  Standards  and  Products,  Attention:  Chief, 
Computer  Security  Standards. 
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Director 
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PREFACE 


The  trusted  computer  system  evaluation  criteria  defined  in  this  document  classify  systems 
into  four  broad  hierarchical  divisions  of  enhanced  security  protection.  They  provide  a  basis 
for  the  evaluation  of  effectiveness  of  security  controls  built  into  automatic  data  processing 
system  products.  The  criteria  were  developed  with  three  objectives  in  mind:  (a)  to  provide 
users  with  a  yardstick  with  which  to  assess  the  degree  of  trust  that  can  be  placed  in 
computer  systems  for  the  secure  processing  of  classified  or  other  sensitive  information;  (b) 
to  provide  guidance  to  manufacturers  as  to  what  to  build  into  their  new,  widely-available 
trusted  commercial  products  in  order  to  satisfy  trust  requirements  for  sensitive  applications; 
and  (c)  to  provide  a  basis  for  specifying  security  requirements  in  acquisition  specifications. 
Two  types  of  requirements  are  delineated  for  secure  processing:  (a)  specific  security  feature 
requirements  and  (b)  assurance  requirements.  Some  of  the  latter  requirements  enable 
evaluation  personnel  to  determine  if  the  required  features  are  present  and  functioning  as 
intended.  Though  the  criteria  are  application-independent,  it  is  recognized  that  the  specific 
security  feature  requirements  may  have  to  be  interpreted  when  applying  the  criteria  to 
specific  applications  or  other  special  processing  environments.  The  underlying  assurance 
requirements  can  be  applied  across  the  entire  spectrum  of  ADP  system  or  application 
processing  environments  without  special  interpretation. 
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INTRODUCTION 


Historical  Perspective 

In  October  1967,  a  task  force  was  assembled  under  the  auspices  of  the  Defense  Science 
Board  to  address  computer  security  safeguards  that  would  protect  classified  information  in 
remote-access,  resource-sharing  computer  systems.  The  Task  Force  report,  "Security 
Controls  for  Computer  Systems,"  published  in  February  1970,  made  a  number  of  policy  and 
technical  recommendations  on  actions  to  be  taken  to  reduce  the  threat  of  compromise  of 
classified  information  processed  on  remote-access  computer  systems. [34]  Department  of 
Defense  Directive  5200.28  and  its  accompanying  manual  DoD  5200. 28-M,  published  in 
1972  and  1973  respectivley,  responded  to  one  of  these  recommendations  by  establishing 
uniform  DoD  policy,  security  requirements,  administrative  controls,  and  technical  measures 
to  protect  classified  information  processed  by  DoD  computer  systems. [8;9]  Research  and 
development  work  undertaken  by  the  Air  Force,  Advanced  Research  Projects  Agency,  and 
other  defense  agencies  in  the  early  and  mid  70 's  developed  and  demonstrated  solution 
approaches  for  the  technical  problems  associated  with  controlling  the  flow  of  information  in 
resource  and  information  sharing  computer  systems.[l]  The  DoD  Computer  Security 
Initiative  was  started  in  1977  under  the  auspices  of  the  Under  Secretary  of  Defense  for 
Research  and  Engineering  to  focus  DoD  efforts  addressing  computer  security  issues. [33] 

Concurrent  with  DoD  efforts  to  address  computer  security  issues,  work  was  begun  under 
the  leadership  of  the  National  Bureau  of  Standards  (NBS)  to  define  problems  and  solutions 
for  building,  evaluating,  and  auditing  secure  computer  systems.[l7]  As  part  of  this  work 
NBS  held  two  invitational  workshops  on  the  subject  of  audit  and  evaluation  of  computer 
security. [20;28]  The  first  was  held  in  March  1977,  and  the  second  in  November  of  1978. 
One  of  the  products  of  the  second  workshop  was  a  definitive  paper  on  the  problems  related 
to  providing  criteria  for  the  evaluation  of  technical  computer  security  effectiveness. [20]  As 
an  outgrowth  of  recommendations  from  this  report,  and  in  support  of  the  DoD  Computer 
Security  Initiative,  the  MITRE  Corporation  began  work  on  a  set  of  computer  security 
evaluation  criteria  that  could  be  used  to  assess  the  degree  of  trust  one  could  place  in  a 
computer  system  to  protect  classified  data.[24;25;31]  The  preliminary  concepts  for 
computer  security  evaluation  were  defined  and  expanded  upon  at  invitational  workshops  and 
symposia  whose  participants  represented  computer  security  expertise  drawn  from  industry 
and  academia  in  addition  to  the  government.  Their  work  has  since  been  subjected  to  much 
peer  review  and  constructive  technical  criticism  from  the  DoD,  industrial  research  and 
development  organizations,  universities,  and  computer  manufacturers. 

The  DoD  Computer  Security  Center  (the  Center)  was  formed  in  January  1981  to  staff  and 
expand  on  the  work  started  by  the  DoD  Computer  Security  Initiative.! 1 5]  A  major  goal  of 
the  Center  as  given  in  its  DoD  Charter  is  to  encourage  the  widespread  availability  of  trusted 
computer  systems  for  use  by  those  who  process  classified  or  other  sensitive  information. [10] 
The  criteria  presented  in  this  document  have  evolved  from  the  earlier  NBS  and  MITRE 
evaluation  material. 
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Introduction 


Scope 

The  trusted  computer  system  evaluation  criteria  defined  in  this  document  apply  to  both 
trusted  general-purpose  and  trusted  embedded  (e.g.,  those  dedicated  to  a  specific 
application)  automatic  data  processing  (ADP)  systems.  Included  are  two  distinct  sets  of 
requirements:  I)  specific  security  feature  requirements;  and  2)  assurance  requirements.  The 
specific  feature  requirements  encompass  the  capabilities  typically  found  in  information 
processing  systems  employing  general-purpose  operating  systems  that  are  distinct  from  the 
applications  programs  being  supported.  The  assurance  requirements,  on  the  other  hand, 
apply  to  systems  that  cover  the  full  range  of  computing  environments  from  dedicated 
controllers  to  full  range  multilevel  secure  resource  sharing  systems. 


Purpose 

As  outlined  in  the  Preface,  the  criteria  have  been  developed  for  a  number  of  reasons: 

*  To  provide  users  with  a  metric  with  which  to  evaluate  the  degree  of  trust  that  can 
be  placed  in  computer  systems  for  the  secure  processing  of  classified  and  other 
sensitive  information. 

*  To  provide  guidance  to  manufacturers  as  to  what  security  features  to  build  into 
their  new  and  planned,  commercial  products  in  order  to  provide  widely  available 
systems  that  satisfy  trust  requirements  for  sensitive  applications. 

*  To  provide  a  basis  for  specifying  security  requirements  in  acquisition 
specifications. 

With  respect  to  the  first  purpose  for  development  of  the  criteria,  i.e.,  providing  users  with 
a  security  evaluation  metric,  evaluations  can  be  delineated  into  two  types:  (a)  an  evaluation 
can  be  performed  on  a  computer  product  from  a  perspective  that  excludes  the  application 
environment;  or,  (b)  it  can  be  done  to  assess  whether  appropriate  security  measures  have 
been  taken  to  permit  the  system  to  be  used  operationally  in  a  specific  environment.  The 
former  type  of  evaluation  is  done  by  the  Computer  Security  Center  through  the  Commercial 
Product  Evaluation  Process.  That  process  is  described  in  Appendix  A. 

The  latter  type  of  evaluation,  i.e.,  those  done  for  the  purpose  of  assessing  a  system's 
security  attributes  with  respect  to  a  specific  operational  mission,  is  known  as  a  certification 
evaluation.  It  must  be  understood  that  the  completion  of  a  formal  product  evaluation  does 
not  constitute  certification  or  accreditation  for  the  system  to  be  used  in  any  specific 
application  environment.  On  the  contrary,  the  evaluation  report  only  provides  a  trusted 
computer  system's  evaluation  rating  along  with  supporting  data  describing  the  product 
system's  strengths  and  weaknesses  from  a  computer  security  point  of  view.  The  system 
security  certification  and  the  formal  approval/accreditation  procedure,  done  in  accordance 
with  the  applicable  policies  of  the  issuing  agencies,  must  still  be  followed  before  a  system 
can  be  approved  for  use  in  processing  or  handling  classified  information. [8;9] 

The  trusted  computer  system  evaluation  criteria  will  be  used  directly  and  indirectly  in  the 
certification  process.  Along  with  applicable  policy,  it  will  be  used  directly  as  the  basis  for 
evaluation  of  the  total  system  and  for  specifying  system  security  and  certification 
requirements  for  new  acquisitions.  Where  a  system  being  evaluated  for  certification 
employs  a  product  that  has  undergone  a  Commercial  Product  Evaluation,  reports  from  that 
process  will  be  used  as  input  to  the  certification  evaluation.  Technical  data  will  be 
furnished  to  designers,  evaluators  and  the  Designated  Approving  Authorities  to  support 
their  needs  for  making  decisions. 
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Fundamental  Computer  Security  Requirements 

Any  discussion  of  computer  security  necessarily  starts  from  a  statement  of  requirements, 
i.e.,  what  it  really  means  to  call  a  computer  system  "secure."  In  general,  secure  systems 
will  control,  through  use  of  specific  security  features,  access  to  information  such  that  only 
properly  authorized  individuals,  or  processes  operating  on  their  behalf,  will  have  access  to 
read,  write,  create,  or  delete  information.  Six  fundamental  requirements  are  derived  from 
this  basic  statement  of  objective:  four  deal  with  what  needs  to  be  provided  to  control 
access  to  information;  and  two  deal  with  how  one  can  obtain  credible  assurances  that  this  is 
accomplished  in  a  trusted  computer  system. 


Policy 

Requirement  1  -  SECURITY  POLICY  -  There  must  be  an  explicit  and 
well-defined  security  policy  enforced  by  the  system.  Given  identified 
subjects  and  objects,  there  must  be  a  set  of  rules  that  are  used  by  the 
system  to  determine  whether  a  given  subject  can  be  permitted  to  gain  access 
to  a  specific  object.  Computer  systems  of  interest  must  enforce  a 
mandatory  security  policy  that  can  effectively  implement  access  rules  for 
handling  sensitive  (e.g.,  classified)  information. [7]  These  rules  include 
requirements  such  as:  No  person  lacking  proper  personnel  security 
clearance  shall  obtain  access  to  classified  information.  In  addition, 
discretionary  security  controls  are  required  to  ensure  that  only  selected  users 
or  groups  of  users  may  obtain  access  to  data  (e.g.,  based  on  a  need- 
to-know). 

Requirement  2  -  MARKING  -  Access  control  labels  must  be  associated 
with  objects.  In  order  to  control  access  to  information  stored  in  a 
computer,  according  to  the  rules  of  a  mandatory  security  policy,  it  must  be 
possible  to  mark  every  object  with  a  label  that  reliably  identifies  the 
object's  sensitivity  level  (e.g.,  classification),  and/or  the  modes  of  access 
accorded  those  subjects  who  may  potentially  access  the  object. 


Accountability 

Requirement  3  -  IDENTIFICATION  -  Individual  subjects  must  be 
identified.  Each  access  to  information  must  be  mediated  based  on  who  is 
accessing  the  information  and  what  classes  of  information  they  are 
authorized  to  deal  with.  This  identification  and  authorization  information 
must  be  securely  maintained  by  the  computer  system  and  be  associated  with 
every  active  element  that  performs  some  security-relevant  action  in  the 
system. 

Requirement  4  -  ACCOUNTABILITY  •  Audit  information  must  be 
selectively  kept  and  protected  so  that  actions  affecting  security  can  be 
traced  to  the  responsible  party.  A  trusted  system  must  be  able  to  record 
the  occurrences  of  security-relevant  events  in  an  audit  log.  The  capability  to 
select  the  audit  events  to  be  recorded  is  necessary  to  minimize  the  expense 
of  auditing  and  to  allow  efficient  analysis.  Audit  data  must  be  protected 
from  modification  and  unauthorized  destruction  to  permit  detection  and 
after-the-fact  investigations  of  security  violations. 
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Assurance 

Requirement  5  -  ASSURANCE  -  The  computer  system  must  contain 
hardware/software  mechanisms  that  can  be  independently  evaluated  to 
provide  sufficient  assurance  that  the  system  enforces  requirements  1 
through  4  above.  In  order  to  assure  that  the  four  requirements  of  Security 
Policy,  Marking,  Identification,  and  Accountability  are  enforced  by  a 
computer  system,  there  must  be  some  identified  and  unified  collection  of 
hardware  and  software  controls  that  perform  those  functions.  These 
mechanisms  are  typically  embedded  in  the  operating  system  and  are  designed 
to  carry  out  the  assigned  tasks  in  a  secure  manner.  The  basis  for  trusting 
such  system  mechanisms  in  their  operational  setting  must  be  clearly 
documented  such  that  it  is  possible  to  independently  examine  the  evidence 
to  evaluate  their  sufficiency. 

Requirement  6  -  CONTINUOUS  PROTECTION  -  The  trusted 
mechanisms  that  enforce  these  basic  requirements  must  be  continuously 
protected  against  tampering  and/or  unauthorized  changes.  No  computer 
system  can  be  considered  truly  secure  if  the  basic  hardware  and  software 
mechanisms  that  enforce  the  security  policy  are  themselves  subject  to 
unauthorized  modification  or  subversion.  The  continuous  protection 
requirement  has  direct  implications  throughout  the  computer  system's  life- 
cycle. 

These  fundamental  requirements  form  the  basis  for  the  individual  evaluation  criteria 
applicable  for  each  evaluation  division  and  class.  The  interested  reader  is  referred  to 
Section  5  of  this  document,  "Control  Objectives  for  Trusted  Computer  Systems,"  for  a 
more  complete  discussion  and  further  amplification  of  these  fundamental  requirements  as 
they  apply  to  general-purpose  information  processing  systems  and  to  Section  7  for 
amplification  of  the  relationship  between  Policy  and  these  requirements. 


Structure  of  the  Document 

The  remainder  of  this  document  is  divided  into  two  parts,  four  appendices,  and  a  glossary. 
Part  I  (Sections  I  through  4)  presents  the  detailed  criteria  derived  from  the  fundamental 
requirements  described  above  and  relevant  to  the  rationale  and  policy  excerpts  contained  in 
Part  II. 

Part  II  (Sections  5  through  10)  provides  a  discussion  of  basic  objectives,  rationale,  and 
national  policy  behind  the  development  of  the  criteria,  and  guidelines  for  developers 
pertaining  to:  mandatory  access  control  rules  implementation,  the  covert  channel  problem, 
and  security  testing.  It  is  divided  into  six  sections.  Section  5  discusses  the  use  of  control 
objectives  in  general  and  presents  the  three  basic  control  objectives  of  the  criteria.  Section 
6  provides  the  theoretical  basis  behind  the  criteria.  Section  7  gives  excerpts  from  pertinent 
regulations,  directives,  OMB  Circulars,  and  Executive  Orders  which  provide  the  basis  for 
many  trust  requirements  for  processing  nationally  sensitive  and  classified  information  with 
computer  systems.  Section  8  provides  guidance  to  system  developers  on  expectations  in 
dealing  with  the  covert  channel  problem.  Section  9  provides  guidelines  dealing  with 
mandatory  security.  Section  10  provides  guidelines  for  security  testing.  There  are  four 
appendices,  including  a  description  of  the  Trusted  Computer  System  Commercial  Products 
Evaluation  Process  (Appendix  A),  summaries  of  the  evaluation  divisions  (Appendix  B)  and 
classes  (Appendix  C),  and  finally  a  directory  of  requirements  ordered  alphabetically.  In 
addition,  there  is  a  glossary. 
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Structure  of  the  Criteria 

The  criteria  are  divided  into  four  divisions:  D,  C,  B,  and  A  ordered  in  a  hierarchical 
manner  with  the  highest  division  (A)  being  reserved  for  systems  providing  the  most 
comprehensive  security.  Each  division  represents  a  major  improvement  in  the  overall 
confidence  one  can  place  in  the  system  for  the  protection  of  sensitive  information.  Within 
divisions  C  and  B  there  are  a  number  of  subdivisions  known  as  classes.  The  classes  are  also 
ordered  in  a  hierarchical  manner  with  systems  representative  of  division  C  and  lower  classes 
of  division  B  being  characterized  by  the  set  of  computer  security  mechanisms  that  they 
possess.  Assurance  of  correct  and  complete  design  and  implementation  for  these  systems  is 
gained  mostly  through  testing  of  the  security-relevant  portions  of  the  system.  The  security¬ 
relevant  portions  of  a  system  are  referred  to  throughout  this  document  as  the  Trusted 
Computing  Base  (TCB).  Systems  representative  of  higher  classes  in  division  B  and  division 
A  derive  their  security  attributes  more  from  their  design  and  implementation  structure. 
Increased  assurance  that  the  required  features  are  operative,  correct,  and  tamperproof  under 
all  circumstances  is  gained  through  progressively  more  rigorous  analysis  during  the  design 
process. 

Within  each  class,  four  major  sets  of  criteria  are  addressed.  The  first  three  represent 
features  necessary  to  satisfy  the  broad  control  objectives  of  Security  Policy,  Accountability, 
and  Assurance  that  are  discussed  in  Part  II,  Section  5.  The  fourth  set,  Documentation, 
describes  the  type  of  written  evidence  in  the  form  of  user  guides,  manuals,  and  the  test  and 
design  documentation  required  for  each  class. 

A  reader  using  this  publication  for  the  first  time  may  find  it  helpful  to  first  read  Part  II, 
before  continuing  on  with  Part  I. 
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PARTI:  THE  CRITERIA 


Highlighting  is  used  in  Part  I  to  indicate  criteria  not  contained  in  a  lower  class  or  changes 
and  additions  to  already  defined  criteria.  Where  there  is  no  highlighting,  requirements  have 
been  carried  over  from  lower  classes  without  addition  or  modification. 


Division  D 
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1 .0  DIVISION  D:  MINIMAL  PROTECTION 


This  division  contains  only  one  class.  It  is  reserved  for  those  systems  that  have  been 
evaluated  but  that  fail  to  meet  the  requirements  for  a  higher  evaluation  class. 


Division  C 
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2.0  DIVISION  C:  DISCRETIONARY  PROTECTION 


Classes  in  this  division  provide  for  discretionary  (need-to-know)  protection  and,  through  the 
inclusion  of  audit  capabilities,  for  accountability  of  subjects  and  the  actions  they  initiate. 
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2.1  CLASS  (Cl):  DISCRETIONARY  SECURITY  PROTECTION 


The  Trusted  Computing  Base  (TCB)  of  a  class  (Cl)  system  nominally  satisfies  the 
discretionary  security  requirements  by  providing  separation  of  users  and  data.  It 
incorporates  some  form  of  credible  controls  capable  of  enforcing  access  limitations  on  an 
individual  basis,  i.  e. ,  ostensibly  suitable  for  allowing  users  to  be  able  to  protect  project  or 
private  information  and  to  keep  other  users  from  accidentally  reading  or  destroying  their 
data.  The  class  (Cl)  environment  is  expected  to  be  one  of  cooperating  users  processing 
data  at  the  same  level (s)  of  sensitivity.  The  following  are  minimal  requirements  for 
systems  assigned  a  class  (Cl)  rating: 


2.1.1  Security  Policy 

2. 1 . 1 . 1  Discretionary  Access  Control 

The  TCB  shall  define  and  control  access  between  named  users  and 
named  objects  (e.g.,  files  and  programs)  in  the  ADP  system.  The 
enforcement  mechanism  (e.g.,  self/group/public  controls,  access 
control  lists)  shall  allow  users  to  specify  and  control  sharing  of  those 
objects  by  named  individuals  or  defined  groups  or  both. 


2.1.2  Accountability 

2. 1 .2. 1  Identification  and  Authentication 

The  TCB  shall  require  users  to  identify  themselves  to  it  before 
beginning  to  perform  any  other  actions  that  the  TCB  is  expected  to 
mediate.  Furthermore,  the  TCB  shall  use  a  protected  mechanism 
(e.g.,  passwords)  to  authenticate  the  user's  identity.  The  TCB  shall 
protect  authentication  data  so  that  it  cannot  be  accessed  by  any 
unauthorized  user. 
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2.1.3  Assurance 

2 . 1 . 3 . 1  Operational  Assurance 

2. 1 .3. 1 . 1  System  Architecture 

The  TCB  shall  maintain  a  domain  for  its  own  execution  that 
protects  it  from  external  interference  or  tampering  (e.g.,  by 
modification  of  its  code  or  data  structures).  Resources 
controlled  by  the  TCB  may  be  a  defined  subset  of  the  subjects 
and  objects  in  the  ADP  system. 

2. 1.3. 1.2  System  Integrity 

Hardware  and/or  software  features  shall  be  provided  that  can  be 
used  to  periodically  validate  the  correct  operation  of  the  on-site 
hardware  and  firmware  elements  of  the  TCB. 

2 . 1 . 3 . 2  Life-Cycle  Assurance 

2. 1.3. 2. 1  Security  Testing 

The  security  mechanisms  of  the  ADP  system  shall  be  tested  and 
found  to  work  as  claimed  in  the  system  documentation.  Testing 
shall  be  done  to  assure  that  there  are  no  obvious  ways  for  an 
unauthorized  user  to  bypass  or  otherwise  defeat  the  security 
protection  mechanisms  of  the  TCB.  (See  the  Security  Testing 
guidelines.) 


2.1.4  Documentation 

2. 1 .4. 1  Security  Features  User' s  Guide 

A  single  summary,  chapter,  or  manual  in  user  documentation  shall 
describe  the  protection  mechanisms  provided  by  the  TCB,  guidelines 
on  their  use,  and  how  they  interact  with  one  another. 

2. 1.4.2  Trusted  Facility  Manual 

A  manual  addressed  to  the  ADP  system  administrator  shall  present 
cautions  about  functions  and  privileges  that  should  be  controlled  when 
running  a  secure  facility. 

2. 1.4.3  Test  Documentation 

The  system  developer  shall  provide  to  the  evaluators  a  document  that 
describes  the  test  plan  and  results  of  the  security  mechanisms' 
functional  testing. 
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2. 1.4. 4  Design  Documentation 

Documentation  shall  be  available  that  provides  a  description  of  the 
manufacturer's  philosophy  of  protection  and  an  explanation  of  how 
this  philosophy  is  translated  into  the  TCB.  If  the  TCB  is  composed  of 
distinct  modules,  the  interfaces  between  these  modules  shall  be 
described. 
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2.2  CLASS  (C2):  CONTROLLED  ACCESS  PROTECTION 


Systems  in  this  class  enforce  a  more  finely  grained  discretionary  access  control  than  (Cl) 
systems,  making  users  individually  accountable  for  their  actions  through  login  procedures, 
auditing  of  security-relevant  events,  and  resource  isolation.  The  following  are  minimal 
requirements  for  systems  assigned  a  class  (C2)  rating: 


2.2.1  Security  Policy 

2.2. 1 . 1  Discretionary  Access  Control 


The  TCB  shall  define  and  control  access  between  named  users  and  named 
objects  (e.g.,  files  and  programs)  in  the  ADP  system.  The  enforcement 
mechanism  (e.g.,  self/group/public  controls,  access  control  lists)  shall 
allow  users  to  specify  and  control  sharing  of  those  objects  by  named 
individuals,  or  defined  groups  of  individuals,  or  by  both.  The 
discretionary  access  control  mechanism  shall,  either  by  explicit  user 
action  or  by  default,  provide  that  objects  are  protected  from 
unauthorized  access.  These  access  controls  shall  be  capable  of 
including  or  excluding  access  to  the  granularity  of  a  single  user. 
Access  permission  to  an  object  by  users  not  already  possessing  access 
permission  shall  only  be  assigned  by  authorized  users. 


2.2. 1.2  Object  Reuse 


When  a  storage  object  is  initially  assigned,  allocated,  or  reallocated  to 
a  subject  from  the  TCB's  pool  of  unused  storage  objects,  the  TCB 
shall  assure  that  the  object  contains  no  data  for  which  the  subject  is 
not  authorized. 
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2.2.2  Accountability 

2.2.2. 1  Identification  and  Authentication 

The  TCB  shall  require  users  to  identify  themselves  to  it  before  beginning 
to  perform  any  other  actions  that  the  TCB  is  expected  to  mediate. 
Furthermore,  the  TCB  shall  use  a  protected  mechanism  (e.g.,  passwords) 
to  authenticate  the  user's  identity.  The  TCB  shall  protect  authentication 
data  so  that  it  cannot  be  accessed  by  any  unauthorized  user.  The  TCB 
shall  be  able  to  enforce  individual  accountability  by  providing  the 
capability  to  uniquely  identify  each  individual  ADP  system  user.  The 
TCB  shall  also  provide  the  capability  of  associating  this  identity  with 
all  auditable  actions  taken  by  that  individual. 

2. 2. 2. 2  Audit 

The  TCB  shall  be  able  to  create,  maintain,  and  protect  from 
modification  or  unauthorized  access  or  destruction  an  audit  trail  of 
accesses  to  the  objects  it  protects.  The  audit  data  shall  be  protected 
by  the  TCB  so  that  read  access  to  it  is  limited  to  those  who  are 
authorized  for  audit  data.  The  TCB  shall  be  able  to  record  the 
following  types  of  events:  use  of  identification  and  authentication 
mechanisms,  introduction  of  objects  into  a  user's  address  space  (e.g., 
file  open,  program  initiation),  deletion  of  objects,  and  actions  taken 
by  computer  operators  and  system  administrators  and/or  system 
security  officers.  For  each  recorded  event,  the  audit  record  shall 
identify:  date  and  time  of  the  event,  user,  type  of  event,  and  success 
or  failure  of  the  event.  For  identification/authentication  events  the 
origin  of  request  (e.g.,  terminal  ID)  shall  be  included  in  the  audit 
record.  For  events  that  introduce  an  object  into  a  user's  address 
space  and  for  object  deletion  events  the  audit  record  shall  include  the 
name  of  the  object.  The  ADP  system  administrator  shall  be  able  to 
selectively  audit  the  actions  of  any  one  or  more  users  based  on 
individual  identity. 


2.2.3  Assurance 

2 . 2 . 3 . 1  Operational  Assurance 

2 . 2 . 3 . 1 . 1  System  Architecture 

The  TCB  shall  maintain  a  domain  for  its  own  execution  that 
protects  it  from  external  interference  or  tampering  (e.g.,  by 
modification  of  its  code  or  data  structures).  Resources  controlled 
by  the  TCB  may  be  a  defined  subset  of  the  subjects  and  objects  in 
the  ADP  system.  The  TCB  shall  isolate  the  resources  to  be 
protected  so  that  they  are  subject  to  the  access  control  and 
auditing  requirements. 
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2 . 2 . 3 . 1 . 2  System  Integrity 

Hardware  and/or  software  features  shall  be  provided  that  can  be 
used  to  periodically  validate  the  correct  operation  of  the  on-site 
hardware  and  firmware  elements  of  the  TCB. 

2. 2. 3. 2  Life-Cycle  Assurance 

2 . 2 . 3 . 2 . 1  Security  Testing 

The  security  mechanisms  of  the  ADP  system  shall  be  tested  and 
found  to  work  as  claimed  in  the  system  documentation.  Testing 
shall  be  done  to  assure  that  there  are  no  obvious  ways  for  an 
unauthorized  user  to  bypass  or  otherwise  defeat  the  security 
protection  mechanisms  of  the  TCB.  Testing  shall  also  include  a 
search  for  obvious  flaws  that  would  allow  violation  of  resource 
isolation,  or  that  would  permit  unauthorized  access  to  the  audit 
or  authentication  data.  (See  the  Security  Testing  guidelines.) 


2.2.4  Documentation 

2.2.4. 1  Security  Features  User's  Guide 

A  single  summary,  chapter,  or  manual  in  user  documentation  shall 
describe  the  protection  mechanisms  provided  by  the  TCB,  guidelines  on 
their  use,  and  how  they  interact  with  one  another. 

2. 2. 4. 2  Trusted  Facility  Manual 

A  manual  addressed  to  the  ADP  system  administrator  shall  present 
cautions  about  functions  and  privileges  that  should  be  controlled  when 
running  a  secure  facility.  The  procedures  for  examining  and 
maintaining  the  audit  files  as  well  as  the  detailed  audit  record 
structure  for  each  type  of  audit  event  shall  be  given. 

2. 2.4. 3  Test  Documentation 

The  system  developer  shall  provide  to  the  evaluators  a  document  that 
describes  the  test  plan  and  results  of  the  security  mechanisms'  functional 
testing. 

2. 2. 4. 4  Design  Documentation 

Documentation  shall  be  available  that  provides  a  description  of  the 
manufacturer's  philosophy  of  protection  and  an  explanation  of  how  this 
philosophy  is  translated  into  the  TCB.  If  the  TCB  is  composed  of 
distinct  modules,  the  interfaces  between  these  modules  shall  be  described. 
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3.0  DIVISION  B:  MANDATORY  PROTECTION 


The  notion  of  a  TCB  that  preserves  the  integrity  of  sensitivity  labels  and  uses  them  to 
enforce  a  set  of  mandatory  access  control  rules  is  a  major  requirement  in  this  division. 
Systems  in  this  division  must  carry  the  sensitivity  labels  with  major  data  structures  in  the 
system.  The  system  developer  also  provides  the  security  policy  model  on  which  the  TCB  is 
based  and  furnishes  a  specification  of  the  TCB.  Evidence  must  be  provided  to  demonstrate 
that  the  reference  monitor  concept  has  been  implemented. 
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3.1  CLASS  (B1):  LABELED  SECURITY  PROTECTION 


Class  (Bl)  systems  require  all  the  features  required  for  class  <C2).  In  addition,  an 
informal  statement  of  the  security  policy  model,  data  labeling,  and  mandatory  access 
control  over  named  subjects  and  objects  must  be  present.  The  capability  must  exist  for 
accurately  labeling  exported  information.  Any  flaws  identified  by  testing  must  be 
removed.  The  following  are  minimal  requirements  for  systems  assigned  a  class  (Bl) 
rating: 


3.1.1  Security  Policy 

3. 1 . 1 . 1  Discretionary  Access  Control 

The  TCB  shall  define  and  control  access  between  named  users  and  named 
objects  (e.g.,  files  and  programs)  in  the  ADP  system.  The  enforcement 
mechanism  (e.g.,  self/group/public  controls,  access  control  lists)  shall 
allow  users  to  specify  and  control  sharing  of  those  objects  by  named 
individuals,  or  defined  groups  of  individuals,  or  by  both.  The 
discretionary  access  control  mechanism  shall,  either  by  explicit  user 
action  or  by  default,  provide  that  objects  are  protected  from 
unauthorized  access.  These  access  controls  shall  be  capable  of  including 
or  excluding  access  to  the  granularity  of  a  single  user.  Access 
permission  to  an  object  by  users  not  already  possessing  access  permission 
shall  only  be  assigned  by  authorized  users. 

3. 1.1. 2  Object  Reuse 

When  a  storage  object  is  initially  assigned,  allocated,  or  reallocated  to  a 
subject  from  the  TCB's  pool  of  unused  storage  objects,  the  TCB  shall 
assure  that  the  object  contains  no  data  for  which  the  subject  is  not 
authorized. 

3. 1.1. 3  Labels 

Sensitivity  labels  associated  with  each  subject  and  storage  object 
under  its  control  (e.g.,  process,  file,  segment,  device)  shall  be 
maintained  by  the  TCB.  These  labels  shall  be  used  as  the  basis  for 
mandatory  access  control  decisions.  In  order  to  import  non-labeled 
data,  the  TCB  shall  request  and  receive  from  an  authorized  user  the 
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security  level  of  the  data,  and  all  such  actions  shall  be  auditable  by  the 
TCB. 

3. 1.1.3. 1  Label  Integrity 

Sensitivity  labels  shall  accurately  represent  security  levels  of  the 
specific  subjects  or  objects  with  which  they  are  associated. 
When  exported  by  the  TCB,  sensitivity  labels  shall  accurately 
and  unambiguously  represent  the  internal  labels  and  shall  be 
associated  with  the  information  being  exported. 

3. 1 . 1 .3.2  Exportation  of  Labeled  Information 

The  TCB  shall  designate  each  communication  channel  and  I/O 
device  as  either  single-level  or  multilevel.  Any  change  in  this 
designation  shall  be  done  manually  and  shall  be  auditable  by  the 
TCB.  The  TCB  shall  maintain  and  be  able  to  audit  any  change 
in  the  current  security  level  associated  with  a  single-level 
communication  channel  or  I/O  device. 

3. 1 . 1 .3.2. 1  Exportation  to  Multilevel  Devices 

When  the  TCB  exports  an  object  to  a  multilevel  I/O 
device,  the  sensitivity  label  associated  with  that  object 
shall  also  be  exported  and  shall  reside  on  the  same 
physical  medium  as  the  exported  information  and  shall  be 
in  the  same  form  (i.e.,  machine-readable  or  human- 
readable  form).  When  the  TCB  exports  or  imports  an 
object  over  a  multilevel  communication  channel,  the 
protocol  used  on  that  channel  shall  provide  for  the 
unambiguous  pairing  between  the  sensitivity  labels  and  the 
associated  information  that  is  sent  or  received. 

3. 1 . 1 .3.2.2  Exportation  to  Single-Level  Devices 

Single-level  I/O  devices  and  single-level  communication 
channels  are  not  required  to  maintain  the  sensitivity  labels 
of  the  information  they  process.  However,  the  TCB  shall 
include  a  mechanism  by  which  the  TCB  and  an  authorized 
user  reliably  communicate  to  designate  the  single  security 
level  of  information  imported  or  exported  via  single-level 
communication  channels  or  I/O  devices. 
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3. 1 . 1 .3.2.3  Labeling  Human-Readable  Output 

The  ADP  system  administrator  shall  be  able  to  specify  the 
printable  label  names  associated  with  exported  sensitivity 
labels.  The  TCB  shall  mark  the  beginning  and  end  of  all 
human-readable,  paged,  hardcopy  output  (e.g.,  line  printer 
output)  with  human-readable  sensitivity  labels  that 
properly1  represent  the  sensitivity  of  the  output.  The 
TCB  shall,  by  default,  mark  the  top  and  bottom  of  each 
page  of  human-readable,  paged,  hardcopy  output  (e.g., 
line  printer  output)  with  human-readable  sensitivity  labels 
that  properly1  represent  the  overall  sensitivity  of  the 
output  or  that  properly1  represent  the  sensitivity  of  the 
information  on  the  page.  The  TCB  shall,  by  default  and 
in  an  appropriate  manner,  mark  other  forms  of  human- 
readable  output  (e.g.,  maps,  graphics)  with  human- 
readable  sensitivity  labels  that  properly1  represent  the 
sensitivity  of  the  output.  Any  override  of  these  marking 
defaults  shall  be  auditable  by  the  TCB. 

3. 1 . 1 .4  Mandatory  Access  Control 

The  TCB  shall  enforce  a  mandatory  access  control  policy  over  all 
subjects  and  storage  objects  under  its  control  (e.g.,  processes,  files, 
segments,  devices).  These  subjects  and  objects  shall  be  assigned 
sensitivity  labels  that  are  a  combination  of  hierarchical  classification 
levels  and  non-hierarchical  categories,  and  the  labels  shall  be  used  as 
the  basis  for  mandatory  access  control  decisions.  The  TCB  shall  be 
able  to  support  two  or  more  such  security  levels.  (See  the  Mandatory 
Access  Control  guidelines.)  The  following  requirements  shall  hold  for 
all  accesses  between  subjects  and  objects  controlled  by  the  TCB:  A 
subject  can  read  an  object  only  if  the  hierarchical  classification  in  the 
subject's  security  level  is  greater  than  or  equal  to  the  hierarchical 
classification  in  the  object's  security  level  and  the  non-hierarchical 
categories  in  the  subject's  security  level  include  all  the  non-hierarchi¬ 
cal  categories  in  the  object's  security  level.  A  subject  can  write  an 
object  only  if  the  hierarchical  classification  in  the  subject's  security 
level  is  less  than  or  equal  to  the  hierarchical  classification  in  the 
object's  security  level  and  all  the  non-hierarchical  categories  in  the 
subject's  security  level  are  included  in  the  non-hierarchical  categories 
in  the  object's  security  level. 


1  The  hierarchical  classification  component  in  human-readable  sensitivity  labels  shall  be  equal  to  the 
greatest  hierarchical  classification  of  any  of  the  information  in  the  output  that  the  labels  refer  to;  the 
non-hierarchical  category  component  shall  include  all  of  the  non-hierarchical  categories  of  the 
information  in  the  output  the  labels  refer  to,  but  no  other  non-hierarchical  categories. 
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3.1.2  Accountability 

3. 1 .2. 1  Identification  and  Authentication 

The  TCB  shall  require  users  to  identify  themselves  to  it  before  beginning 
to  perform  any  other  actions  that  the  TCB  is  expected  to  mediate. 
Furthermore,  the  TCB  shall  maintain  authentication  data  that  includes 
information  for  verifying  the  identity  of  individual  users  (e.g., 
passwords)  as  well  as  information  for  determining  the  clearance  and 
authorizations  of  individual  users.  This  data  shall  be  used  by  the  TCB 
to  authenticate  the  user's  identity  and  to  determine  the  security  level 
and  authorizations  of  subjects  that  may  be  created  to  act  on  behalf  of 
the  individual  user.  The  TCB  shall  protect  authentication  data  so  that  it 
cannot  be  accessed  by  any  unauthorized  user.  The  TCB  shall  be  able  to 
enforce  individual  accountability  by  providing  the  capability  to  uniquely 
identify  each  individual  ADP  system  user.  The  TCB  shall  also  provide 
the  capability  of  associating  this  identity  with  all  auditable  actions  taken 
by  that  individual. 

3. 1.2. 2  Audit 

The  TCB  shall  be  able  to  create,  maintain,  and  protect  from  modification 
or  unauthorized  access  or  destruction  an  audit  trail  of  accesses  to  the 
objects  it  protects.  The  audit  data  shall  be  protected  by  the  TCB  so  that 
read  access  to  it  is  limited  to  those  who  are  authorized  for  audit  data. 
The  TCB  shall  be  able  to  record  the  following  types  of  events:  use  of 
identification  and  authentication  mechanisms,  introduction  of  objects 
into  a  user's  address  space  (e.g.,  file  open,  program  initiation),  deletion 
of  objects,  and  actions  taken  by  computer  operators  and  system 
administrators  and/or  system  security  officers.  The  TCB  shall  also  be 
able  to  audit  any  override  of  human-readable  output  markings.  For 
each  recorded  event,  the  audit  record  shall  identify:  date  and  time  of  the 
event,  user,  type  of  event,  and  success  or  failure  of  the  event.  For 
identification/authentication  events  the  origin  of  request  (e.g.,  terminal 
ID)  shall  be  included  in  the  audit  record.  For  events  that  introduce  an 
object  into  a  user's  address  space  and  for  object  deletion  events  the 
audit  record  shall  include  the  name  of  the  object  and  the  object's 
security  level.  The  ADP  system  administrator  shall  be  able  to  selectively 
audit  the  actions  of  any  one  or  more  users  based  on  individual  identity 
and/or  object  security  level. 


3.1.3  Assurance 

3 . 1 . 3 . 1  Operational  Assurance 

3 . 1 . 3 . 1 . 1  System  Architecture 

The  TCB  shall  maintain  a  domain  for  its  own  execution  that 
protects  it  from  external  interference  or  tampering  (e.g.,  by 
modification  of  its  code  or  data  structures).  Resources  controlled 
by  the  TCB  may  be  a  defined  subset  of  the  subjects  and  objects  in 
the  ADP  system.  The  TCB  shall  maintain  process  isolation 
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through  the  provision  of  distinct  address  spaces  under  its 
control.  The  TCB  shall  isolate  the  resources  to  be  protected  so 
that  they  are  subject  to  the  access  control  and  auditing  require¬ 
ments. 

3 . 1 . 3 . 1 . 2  System  Integrity 

Hardware  and/or  software  features  shall  be  provided  that  can  be 
used  to  periodically  validate  the  correct  operation  of  the  on-site 
hardware  and  firmware  elements  of  the  TCB. 

3 . 1 . 3 . 2  Life-Cycle  Assurance 

3 . 1 . 3 . 2 . 1  Security  Testing 

The  security  mechanisms  of  the  ADP  system  shall  be  tested  and 
found  to  work  as  claimed  in  the  system  documentation.  A  team 
of  individuals  who  thoroughly  understand  the  specific  imple¬ 
mentation  of  the  TCB  shall  subject  its  design  documentation, 
source  code,  and  object  code  to  thorough  analysis  and  testing. 
Their  objectives  shall  be:  to  uncover  all  design  and  implementa¬ 
tion  flaws  that  would  permit  a  subject  external  to  the  TCB  to 
read,  change,  or  delete  data  normally  denied  under  the 
mandatory  or  discretionary  security  policy  enforced  by  the  TCB; 
as  well  as  to  assure  that  no  subject  (without  authorization  to  do 
so)  is  able  to  cause  the  TCB  to  enter  a  state  such  that  it  is 
unable  to  respond  to  communications  initiated  by  other  users. 
All  discovered  flaws  shall  be  removed  or  neutralized  and  the 
TCB  retested  to  demonstrate  that  they  have  been  eliminated  and 
that  new  flaws  have  not  been  introduced.  (See  the  Security 
Testing  Guidelines.) 

3. 1.3. 2. 2  Design  Specification  and  Verification 

An  informal  or  formal  model  of  the  security  policy  supported  by 
the  TCB  shall  be  maintained  that  is  shown  to  be  consistent  with 
its  axioms. 


3.1.4  Documentation 

3. 1 .4. 1  Security  Features  User's  Guide 

A  single  summary,  chapter,  or  manual  in  user  documentation  shall 
describe  the  protection  mechanisms  provided  by  the  TCB,  guidelines  on 
their  use,  and  how  they  interact  with  one  another. 

3. 1.4. 2  Trusted  Facility  Manual 

A  manual  addressed  to  the  ADP  system  administrator  shall  present 
cautions  about  functions  and  privileges  that  should  be  controlled  when 
running  a  secure  facility.  The  procedures  for  examining  and  maintaining 
the  audit  files  as  well  as  the  detailed  audit  record  structure  for  each  type 
of  audit  event  shall  be  given.  The  manual  shall  describe  the  operator 
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and  administrator  functions  related  to  security,  to  include  changing 
the  security  characteristics  of  a  user.  It  shall  provide  guidelines  on 
the  consistent  and  effective  use  of  the  protection  features  of  the 
system,  how  they  interact,  how  to  securely  generate  a  new  TCB,  and 
facility  procedures,  warnings,  and  privileges  that  need  to  be  controlled 
in  order  to  operate  the  facility  in  a  secure  manner. 

3. 1.4. 3  Test  Documentation 

The  system  developer  shall  provide  to  the  evaluators  a  document  that 
describes  the  test  plan  and  results  of  the  security  mechanisms'  functional 
testing. 

3. 1.4.4  Design  Documentation 

Documentation  shall  be  available  that  provides  a  description  of  the 
manufacturer's  philosophy  of  protection  and  an  explanation  of  how  this 
philosophy  is  translated  into  the  TCB.  If  the  TCB  is  composed  of 
distinct  modules,  the  interfaces  between  these  modules  shall  be  described. 

An  informal  or  formal  description  of  the  security  policy  model 
enforced  by  the  TCB  shall  be  available  and  an  explanation  provided  to 
show  that  it  is  sufficient  to  enforce  the  security  policy.  The  specific 
TCB  protection  mechanisms  shall  be  identified  and  an  explanation 
given  to  show  that  they  satisfy  the  model. 
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3.2  CLASS  (B2):  STRUCTURED  PROTECTION 


In  class  <B2)  systems,  the  TCB  is  based  on  a  clearly  defined  and  documented  formal 
security  policy  model  that  requires  the  discretionary  and  mandatory  access  control 
enforcement  found  in  class  < Bl )  systems  be  extended  to  all  subjects  and  objects  in  the 
ADP  system.  In  addition,  covert  channels  are  addressed.  The  TCB  must  be  carefully 
structured  into  protection-critical  and  non-protection-critical  elements.  The  TCB  interface 
is  well-defined  and  the  TCB  design  and  implementation  enable  it  to  be  subjected  to  more 
thorough  testing  and  more  complete  review.  Authentication  mechanisms  are  strengthened, 
trusted  facility  management  is  provided  in  the  form  of  support  for  system  administrator 
and  operator  functions,  and  stringent  configuration  management  controls  are  imposed. 
The  system  is  relatively  resistant  to  penetration.  The  following  are  minimal  requirements 
for  systems  assigned  a  class  <B2)  rating: 


3.2.1  Security  Policy 

3.2. 1 . 1  Discretionary  Access  Control 

The  TCB  shall  define  and  control  access  between  named  users  and  named 
objects  (e.g.,  files  and  programs)  in  the  ADP  system.  The  enforcement 
mechanism  (e.g.,  self/group/public  controls,  access  control  lists)  shall 
allow  users  to  specify  and  control  sharing  of  those  objects  by  named 
individuals,  or  defined  groups  of  individuals,  or  by  both.  The 
discretionary  access  control  mechanism  shall,  either  by  explicit  user 
action  or  by  default,  provide  that  objects  are  protected  from 
unauthorized  access.  These  access  controls  shall  be  capable  of  including 
or  excluding  access  to  the  granularity  of  a  single  user.  Access 
permission  to  an  object  by  users  not  already  possessing  access  permission 
shall  only  be  assigned  by  authorized  users. 

3. 2. 1.2  Object  Reuse 

When  a  storage  object  is  initially  assigned,  allocated,  or  reallocated  to  a 
subject  from  the  TCB's  pool  of  unused  storage  objects,  the  TCB  shall 
assure  that  the  object  contains  no  data  for  which  the  subject  is  not 
authorized. 
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3.2. 1.3  Labels 

Sensitivity  labels  associated  with  each  ADP  system  resource  (e.g., 
subject,  storage  object)  that  is  directly  or  indirectly  accessible  by 
subjects  external  to  the  TCB  shall  be  maintained  by  the  TCB.  These 
labels  shall  be  used  as  the  basis  for  mandatory  access  control  decisions. 
In  order  to  import  non-labeled  data,  the  TCB  shall  request  and  receive 
from  an  authorized  user  the  security  level  of  the  data,  and  all  such 
actions  shall  be  auditable  by  the  TCB. 

3. 2. 1.3. 1  Label  Integrity 

Sensitivity  labels  shall  accurately  represent  security  levels  of  the 
specific  subjects  or  objects  with  which  they  are  associated.  When 
exported  by  the  TCB,  sensitivity  labels  shall  accurately  and 
unambiguously  represent  the  internal  labels  and  shall  be  associated 
with  the  information  being  exported. 

3.2. 1 .3.2  Exportation  of  Labeled  Information 

The  TCB  shall  designate  each  communication  channel  and  I/O 
device  as  either  single-level  or  multilevel.  Any  change  in  this 
designation  shall  be  done  manually  and  shall  be  auditable  by  the 
TCB.  The  TCB  shall  maintain  and  be  able  to  audit  any  change  in 
the  current  security  level  associated  with  a  single-level  communica¬ 
tion  channel  or  I/O  device. 

3.2. 1.3.2. 1  Exportation  to  Multilevel  Devices 

When  the  TCB  exports  an  object  to  a  multilevel  I/O  device, 
the  sensitivity  label  associated  with  that  object  shall  also  be 
exported  and  shall  reside  on  the  same  physical  medium  as 
the  exported  information  and  shall  be  in  the  same  form  (i.e. , 
machine-readable  or  human-readable  form).  When  the  TCB 
exports  or  imports  an  object  over  a  multilevel  communica¬ 
tion  channel,  the  protocol  used  on  that  channel  shall 
provide  for  the  unambiguous  pairing  between  the  sensitivity 
labels  and  the  associated  information  that  is  sent  or 
received. 

3. 2. 1.3. 2. 2  Exportation  to  Single-Level  Devices 

Single-level  I/O  devices  and  single-level  communication 
channels  are  not  required  to  maintain  the  sensitivity  labels 
of  the  information  they  process.  However,  the  TCB  shall 
include  a  mechanism  by  which  the  TCB  and  an  authorized 
user  reliably  communicate  to  designate  the  single  security 
level  of  information  imported  or  exported  via  single-level 
communication  channels  or  I/O  devices. 
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3. 2. 1.3. 2. 3  Labeling  Human-Readable  Output 

The  ADP  system  administrator  shall  be  able  to  specify  the 
printable  label  names  associated  with  exported  sensitivity 
labels.  The  TCB  shall  mark  the  beginning  and  end  of  all 
human-readable,  paged,  hardcopy  output  (e.g.,  line  printer 
output)  with  human-readable  sensitivity  labels  that  properly1 
represent  the  sensitivity  of  the  output.  The  TCB  shall,  by 
default,  mark  the  top  and  bottom  of  each  page  of  human- 
readable,  paged,  hardcopy  output  (e.g.,  line  printer  output) 
with  human-readable  sensitivity  labels  that  properly1 
represent  the  overall  sensitivity  of  the  output  or  that 
properly1  represent  the  sensitivity  of  the  information  on  the 
page.  The  TCB  shall,  by  default  and  in  an  appropriate 
manner,  mark  other  forms  of  human-readable  output  (e.g., 
maps,  graphics)  with  human-readable  sensitivity  labels  that 
properly1  represent  the  sensitivity  of  the  output.  Any 
override  of  these  marking  defaults  shall  be  auditable  by  the 
TCB. 

3 . 2 . 1 . 3 . 3  Subject  Sensitivity  Labels 

The  TCB  shall  immediately  notify  a  terminal  user  of  each 
change  in  the  security  level  associated  with  that  user  during  an 
interactive  session.  A  terminal  user  shall  be  able  to  query  the 
TCB  as  desired  for  a  display  of  the  subject's  complete 
sensitivity  label. 

3 . 2 . 1 . 3 . 4  Device  Labels 

The  TCB  shall  support  the  assignment  of  minimum  and 
maximum  security  levels  to  all  attached  physical  devices.  These 
security  levels  shall  be  used  by  the  TCB  to  enforce  constraints 
imposed  by  the  physical  environments  in  which  the  devices  are 
located. 

3. 2. 1.4  Mandatory  Access  Control 

The  TCB  shall  enforce  a  mandatory  access  control  policy  over  all 
resources  (i.e.,  subjects,  storage  objects,  and  I/O  devices)  that  are 
directly  or  indirectly  accessible  by  subjects  external  to  the  TCB. 

These  subjects  and  objects  shall  be  assigned  sensitivity  labels  that  are  a 
combination  of  hierarchical  classification  levels  and  non-hierarchical 
categories,  and  the  labels  shall  be  used  as  the  basis  for  mandatory  access 
control  decisions.  The  TCB  shall  be  able  to  support  two  or  more  such 
security  levels.  (See  the  Mandatory  Access  Control  guidelines.)  The 
following  requirements  shall  hold  for  all  accesses  between  all  subjects 


1  The  hierarchical  classification  component  in  human-readable  sensitivity  labels  shall  be  equal  to  the  greatest 
hierarchical  classification  of  any  of  the  information  in  the  output  that  the  labels  refer  to;  the 
non-hierarchical  category  component  shall  include  all  of  the  non-hierarchical  categories  of  the  information 
in  the  output  the  labels  refer  to,  but  no  other  non-hierarchical  categories. 
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external  to  the  TCB  and  all  objects  directly  or  indirectly  accessible  by 
these  subjects:  A  subject  can  read  an  object  only  if  the  hierarchical 
classification  in  the  subject's  security  level  is  greater  than  or  equal  to  the 
hierarchical  classification  in  the  object's  security  level  and  the 
non-hierarchical  categories  in  the  subject's  security  level  include  all  the 
non-hierarchical  categories  in  the  object's  security  level.  A  subject  can 
write  an  object  only  if  the  hierarchical  classification  in  the  subject's 
security  level  is  less  than  or  equal  to  the  hierarchical  classification  in  the 
object's  security  level  and  all  the  non-hierarchical  categories  in  the 
subject's  security  level  are  included  in  the  non-hierarchical  categories  in 
the  object's  security  level. 


3.2.2  Accountability 

3.2.2. 1  Identification  and  Authentication 

The  TCB  shall  require  users  to  identify  themselves  to  it  before  beginning 
to  perform  any  other  actions  that  the  TCB  is  expected  to  mediate. 
Furthermore,  the  TCB  shall  maintain  authentication  data  that  includes 
information  for  verifying  the  identity  of  individual  users  (e.g.,  passwords) 
as  well  as  information  for  determining  the  clearance  and  authorizations 
of  individual  users.  This  data  shall  be  used  by  the  TCB  to  authenticate 
the  user's  identity  and  to  determine  the  security  level  and  authorizations 
of  subjects  that  may  be  created  to  act  on  behalf  of  the  individual  user. 
The  TCB  shall  protect  authentication  data  so  that  it  cannot  be  accessed 
by  any  unauthorized  user.  The  TCB  shall  be  able  to  enforce  individual 
accountability  by  providing  the  capability  to  uniquely  identify  each 
individual  ADP  system  user.  The  TCB  shall  also  provide  the  capability 
of  associating  this  identity  with  all  auditable  actions  taken  by  that 
individual. 

3. 2. 2. 1.1  Trusted  Path 

The  TCB  shall  support  a  trusted  communication  path  between 
itself  and  user  for  initial  login  and  authentication.  Communica¬ 
tions  via  this  path  shall  be  initiated  exclusively  by  a  user. 


3. 2. 2. 2  Audit 

The  TCB  shall  be  able  to  create,  maintain,  and  protect  from  modification 
or  unauthorized  access  or  destruction  an  audit  trail  of  accesses  to  the 
objects  it  protects.  The  audit  data  shall  be  protected  by  the  TCB  so  that 
read  access  to  it  is  limited  to  those  who  are  authorized  for  audit  data. 
The  TCB  shall  be  able  to  record  the  following  types  of  events:  use  of 
identification  and  authentication  mechanisms,  introduction  of  objects 
into  a  user's  address  space  (e.g.,  file  open,  program  initiation),  deletion 
of  objects,  and  actions  taken  by  computer  operators  and  system 
administrators  and/or  system  security  officers.  The  TCB  shall  also  be 
able  to  audit  any  override  of  human-readable  output  markings.  For  each 
recorded  event,  the  audit  record  shall  identify:  date  and  time  of  the 
event,  user,  type  of  event,  and  success  or  failure  of  the  event.  For 
identification/authentication  events  the  origin  of  request  (e.g.,  terminal 


30 


Division  B  Class  B2 


ID)  shall  be  included  in  the  audit  record.  For  events  that  introduce  an 
object  into  a  user's  address  space  and  for  object  deletion  events  the 
audit  record  shall  include  the  name  of  the  object  and  the  object's 
security  level.  The  ADP  system  administrator  shall  be  able  to  selectively 
audit  the  actions  of  any  one  or  more  users  based  on  individual  identity 
and/or  object  security  level.  The  TCB  shall  be  able  to  audit  the 
identified  events  that  may  be  used  in  the  exploitation  of  covert  storage 
channels. 


3.2.3  Assurance 

3 . 2 . 3 . 1  Operational  Assurance 

3.2.3. 1 . 1  System  Architecture 

The  TCB  shall  maintain  a  domain  for  its  own  execution  that 
protects  it  from  external  interference  or  tampering  (e.g.,  by 
modification  of  its  code  or  data  structures).  The  TCB  shall 
maintain  process  isolation  through  the  provision  of  distinct 
address  spaces  under  its  control.  The  TCB  shall  be  internally 
structured  into  well-defined  largely  independent  modules.  It 
shall  make  effective  use  of  available  hardware  to  separate  those 
elements  that  are  protection-critical  from  those  that  are  not. 
The  TCB  modules  shall  be  designed  such  that  the  principle  of 
least  privilege  is  enforced.  Features  in  hardware,  such  as 
segmentation,  shall  be  used  to  support  logically  distinct  storage 
objects  with  separate  attributes  (namely:  readable,  writeable). 
The  user  interface  to  the  TCB  shall  be  completely  defined  and 
all  elements  of  the  TCB  identified. 

3. 2. 3. 1.2  System  Integrity 

• 

Hardware  and/or  software  features  shall  be  provided  that  can  be 
used  to  periodically  validate  the  correct  operation  of  the  on-site 
hardware  and  firmware  elements  of  the  TCB. 

3 . 2 . 3 . 1 . 3  Covert  Channel  Analysis 

The  system  developer  shall  conduct  a  thorough  search  for  covert 
storage  channels  and  make  a  determination  (either  by  actual 
measurement  or  by  engineering  estimation)  of  the  maximum 
bandwidth  of  each  identified  channel.  (See  the  Covert  Channels 
Guideline  section.) 

3. 2. 3. 1.4  Trusted  Facility  Management 

The  TCB  shall  support  separate  operator  and  administrator 
functions. 
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3. 2. 3. 2  Life-Cycle  Assurance 

3 . 2 . 3 . 2 . 1  Security  Testing 

The  security  mechanisms  of  the  ADP  system  shall  be  tested  and 
found  to  work  as  claimed  in  the  system  documentation.  A  team  of 
individuals  who  thoroughly  understand  the  specific  implementation 
of  the  TCB  shall  subject  its  design  documentation,  source  code, 
and  object  code  to  thorough  analysis  and  testing.  Their  objectives 
shall  be:  to  uncover  all  design  and  implementation  flaws  that 
would  permit  a  subject  external  to  the  TCB  to  read,  change,  or 
delete  data  normally  denied  under  the  mandatory  or  discretionary 
security  policy  enforced  by  the  TCB;  as  well  as  to  assure  that  no 
subject  (without  authorization  to  do  so)  is  able  to  cause  the  TCB 
to  enter  a  state  such  that  it  is  unable  to  respond  to  communica¬ 
tions  initiated  by  other  users.  The  TCB  shall  be  found  relatively 
resistant  to  penetration.  All  discovered  flaws  shall  be  corrected 
and  the  TCB  retested  to  demonstrate  that  they  have  been 
eliminated  and  that  new  flaws  have  not  been  introduced.  Testing 
shall  demonstrate  that  the  TCB  implementation  is  consistent 
with  the  descriptive  top-level  specification.  (See  the  Security 
Testing  Guidelines.) 

3. 2. 3. 2. 2  Design  Specification  and  Verification 

A  formal  model  of  the  security  policy  supported  by  the  TCB  shall 
be  maintained  that  is  proven  consistent  with  its  axioms.  A 

descriptive  top-level  specification  (DTLS)  of  the  TCB  shall  be 
maintained  that  completely  and  accurately  describes  the  TCB  in 
terms  of  exceptions,  error  messages,  and  effects.  It  shall  be 
shown  to  be  an  accurate  description  of  the  TCB  interface. 

3. 2. 3. 2. 3  Configuration  Management 

During  development  and  maintenance  of  the  TCB,  a  configura¬ 
tion  management  system  shall  be  in  place  that  maintains  control 
of  changes  to  the  descriptive  top-level  specification,  other  design 
data,  implementation  documentation,  source  code,  the  running 
version  of  the  object  code,  and  test  fixtures  and  documentation. 
The  configuration  management  system  shall  assure  a  consistent 
mapping  among  all  documentation  and  code  associated  with  the 
current  version  of  the  TCB.  Tools  shall  be  provided  for 
generation  of  a  new  version  of  the  TCB  from  source  code.  Also 
available  shall  be  tools  for  comparing  a  newly  generated  version 
with  the  previous  TCB  version  in  order  to  ascertain  that  only 
the  intended  changes  have  been  made  in  the  code  that  will 
actually  be  used  as  the  new  version  of  the  TCB. 
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3.2.4  Documentation 

3.2.4. 1  Security  Features  User's  Guide 

A  single  summary,  chapter,  or  manual  in  user  documentation  shall 
describe  the  protection  mechanisms  provided  by  the  TCB,  guidelines  on 
their  use,  and  how  they  interact  with  one  another. 

3. 2. 4. 2  Trusted  Facility  Manual 

A  manual  addressed  to  the  ADP  system  administrator  shall  present 
cautions  about  functions  and  privileges  that  should  be  controlled  when 
running  a  secure  facility.  The  procedures  for  examining  and  maintaining 
the  audit  files  as  well  as  the  detailed  audit  record  structure  for  each  type 
of  audit  event  shall  be  given.  The  manual  shall  describe  the  operator  and 
administrator  functions  related  to  security,  to  include  changing  the 
security  characteristics  of  a  user.  It  shall  provide  guidelines  on  the 
consistent  and  effective  use  of  the  protection  features  of  the  system,  how 
they  interact,  how  to  securely  generate  a  new  TCB,  and  facility 
procedures,  warnings,  and  privileges  that  need  to  be  controlled  in  order 
to  operate  the  facility  in  a  secure  manner.  The  TCB  modules  that 
contain  the  reference  validation  mechanism  shall  be  identified.  The 
procedures  for  secure  generation  of  a  new  TCB  from  source  after 
modification  of  any  modules  in  the  TCB  shall  be  described. 

3. 2. 4. 3  Test  Documentation 

The  system  developer  shall  provide  to  the  evaluators  a  document  that 
describes  the  test  plan  and  results  of  the  security  mechanisms'  functional 
testing.  It  shall  include  results  of  testing  the  effectiveness  of  the 
methods  used  to  reduce  covert  channel  bandwidths. 

3. 2. 4. 4  Design  Documentation 

Documentation  shall  be  available  that  provides  a  description  of  the 
manufacturer's  philosophy  of  protection  and  an  explanation  of  how  this 
philosophy  is  translated  into  the  TCB.  The  interfaces  between  the  TCB 
modules  shall  be  described.  A  formal  description  of  the  security  policy 
model  enforced  by  the  TCB  shall  be  available  and  proven  that  it  is 
sufficient  to  enforce  the  security  policy.  The  specific  TCB  protection 
mechanisms  shall  be  identified  and  an  explanation  given  to  show  that 
they  satisfy  the  model.  The  descriptive  top-level  specification  (DTLS) 
shall  be  shown  to  be  an  accurate  description  of  the  TCB  interface. 
Documentation  shall  describe  how  the  TCB  implements  the  reference 
monitor  concept  and  give  an  explanation  why  it  is  tamperproof,  cannot 
be  bypassed,  and  is  correctly  implemented.  Documentation  shall 
describe  how  the  TCB  is  structured  to  facilitate  testing  and  to  enforce 
least  privilege.  This  documentation  shall  also  present  the  results  of 
the  covert  channel  analysis  and  the  tradeoffs  involved  in  restricting 
the  channels.  All  auditable  events  that  may  be  used  in  the 
exploitation  of  known  covert  storage  channels  shall  be  identified.  The 
bandwidths  of  known  covert  storage  channels,  the  use  of  which  is  not 
detectable  by  the  auditing  mechanisms,  shall  be  provided.  (See  the 
Covert  Channel  Guideline  section.) 
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3.3  CLASS  (B3):  SECURITY  DOMAINS 


The  class  (B3)  TCB  must  satisfy  the  reference  monitor  requirements  that  it  mediate  all 
accesses  of  subjects  to  objects,  be  tamperproof,  and  be  small  enough  to  be  subjected  to 
analysis  and  tests.  To  this  end,  the  TCB  is  structured  to  exclude  code  not  essential  to 
security  policy  enforcement,  with  significant  system  engineering  during  TCB  design  and 
implementation  directed  toward  minimizing  its  complexity.  A  security  administrator  is 
supported,  audit  mechanisms  are  expanded  to  signal  security-relevant  events,  and  system 
recovery  procedures  are  required.  The  system  is  highly  resistant  to  penetration.  The 
following  are  minimal  requirements  for  systems  assigned  a  class  (B3)  rating: 


3.3.1  Security  Policy 

3.3. 1 . 1  Discretionary  Access  Control 


The  TCB  shall  define  and  control  access  between  named  users  and  named 
objects  (e.g.,  files  and  programs)  in  the  ADP  system.  The  enforcement 
mechanism  (e.g.,  access  control  lists)  shall  allow  users  to  specify  and 
control  sharing  of  those  objects.  The  discretionary  access  control 
mechanism  shall,  either  by  explicit  user  action  or  by  default,  provide  that 
objects  are  protected  from  unauthorized  access.  These  access  controls 
shall  be  capable  of  specifying,  for  each  named  object,  a  list  of  named 
individuals  and  a  list  of  groups  of  named  individuals  with  their 
respective  modes  of  access  to  that  object.  Furthermore,  for  each  such 
named  object,  it  shall  be  possible  to  specify  a  list  of  named  individuals 
and  a  list  of  groups  of  named  individuals  for  which  no  access  to  the 
object  is  to  be  given.  Access  permission  to  an  object  by  users  not 
already  possessing  access  permission  shall  only  be  assigned  by  authorized 
users. 


3. 3. 1.2  Object  Reuse 


When  a  storage  object  is  initially  assigned,  allocated,  or  reallocated  to  a 
subject  from  the  TCB's  pool  of  unused  storage  objects,  the  TCB  shall 
assure  that  the  object  contains  no  data  for  which  the  subject  is  not 
authorized. 
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3. 3. 1.3  Labels 

Sensitivity  labels  associated  with  each  ADP  system  resource  (e.g., 
subject,  storage  object)  that  is  directly  or  indirectly  accessible  by 
subjects  external  to  the  TCB  shall  be  maintained  by  the  TCB.  These 
labels  shall  be  used  as  the  basis  for  mandatory  access  control  decisions. 
In  order  to  import  non-labeled  data,  the  TCB  shall  request  and  receive 
from  an  authorized  user  the  security  level  of  the  data,  and  all  such 
actions  shall  be  auditable  by  the  TCB. 

3 . 3 . 1 . 3 . 1  Label  Integrity 

Sensitivity  labels  shall  accurately  represent  security  levels  of  the 
specific  subjects  or  objects  with  which  they  are  associated.  When 
exported  by  the  TCB,  sensitivity  labels  shall  accurately  and 
unambiguously  represent  the  internal  labels  and  shall  be  associated 
with  the  information  being  exported. 

3 . 3 . 1 . 3 . 2  Exportation  of  Labeled  Information 

The  TCB  shall  designate  each  communication  channel  and  I/O 
device  as  either  single-level  or  multilevel.  Any  change  in  this 
designation  shall  be  done  manually  and  shall  be  auditable  by  the 
TCB.  The  TCB  shall  maintain  and  be  able  to  audit  any  change  in 
the  current  security  level  associated  with  a  single-level  communica¬ 
tion  channel  or  I/O  device. 

3. 3. 1.3. 2.1  Exportation  to  Multilevel  Devices 

When  the  TCB  exports  an  object  to  a  multilevel  I/O  device, 
the  sensitivity  label  associated  with  that  object  shall  also  be 
exported  and  shall  reside  on  the  same  physical  medium  as 
the  exported  information  and  shall  be  in  the  same  form  (i.e., 
machine-readable  or  human-readable  form).  When  the  TCB 
exports  or  imports  an  object  over  a  multilevel  communica¬ 
tion  channel,  the  protocol  used  on  that  channel  shall 
provide  for  the  unambiguous  pairing  between  the  sensitivity 
labels  and  the  associated  information  that  is  sent  or 
received. 

3. 3. 1.3. 2. 2  Exportation  to  Single-Level  Devices 

Single-level  I/O  devices  and  single-level  communication 
channels  are  not  required  to  maintain  the  sensitivity  labels 
of  the  information  they  process.  However,  the  TCB  shall 
include  a  mechanism  by  which  the  TCB  and  an  authorized 
user  reliably  communicate  to  designate  the  single  security 
level  of  information  imported  or  exported  via  single-level 
communication  channels  or  I/O  devices. 
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3. 3. 1.3. 2. 3  Labeling  Human-Readable  Output 

The  ADP  system  administrator  shall  be  able  to  specify  the 
printable  label  names  associated  with  exported  sensitivity 
labels.  The  TCB  shall  mark  the  beginning  and  end  of  all 
human-readable,  paged,  hardcopy  output  (e.g.,  line  printer 
output)  with  human-readable  sensitivity  labels  that  properly1 
represent  the  sensitivity  of  the  output.  The  TCB  shall,  by 
default,  mark  the  top  and  bottom  of  each  page  of  human- 
readable,  paged,  hardcopy  output  (e.g.,  line  printer  output) 
with  human-readable  sensitivity  labels  that  properly1 
represent  the  overall  sensitivity  of  the  output  or  that 
properly1  represent  the  sensitivity  of  the  information  on  the 
page.  The  TCB  shall,  by  default  and  in  an  appropriate 
manner,  mark  other  forms  of  human-readable  output  (e.g., 
maps,  graphics)  with  human-readable  sensitivity  labels  that 
properly1  represent  the  sensitivity  of  the  output.  Any 
override  of  these  marking  defaults  shall  be  auditable  by  the 
TCB. 

3 . 3 . 1 . 3 . 3  Subject  Sensitivity  Labels 

The  TCB  shall  immediately  notify  a  terminal  user  of  each  change 
in  the  security  level  associated  with  that  user  during  an  interactive 
session.  A  terminal  user  shall  be  able  to  query  the  TCB  as  desired 
for  a  display  of  the  subject's  complete  sensitivity  label. 

3 . 3 . 1 . 3 . 4  Device  Labels 

The  TCB  shall  support  the  assignment  of  minimum  and  maximum 
security  levels  to  all  attached  physical  devices.  These  security 
levels  shall  be  used  by  the  TCB  to  enforce  constraints  imposed  by 
the  physical  environments  in  which  the  devices  are  located. 

3.3. 1 .4  Mandatory  Access  Control 

The  TCB  shall  enforce  a  mandatory  access  control  policy  over  all 
resources  (i.e.,  subjects,  storage  objects,  and  I/O  devices)  that  are 
directly  or  indirectly  accessible  by  subjects  external  to  the  TCB.  These 
subjects  and  objects  shall  be  assigned  sensitivity  labels  that  are  a 
combination  of  hierarchical  classification  levels  and  non-hierarchical 
categories,  and  the  labels  shall  be  used  as  the  basis  for  mandatory  access 
control  decisions.  The  TCB  shall  be  able  to  support  two  or  more  such 
security  levels.  (See  the  Mandatory  Access  Control  guidelines.)  The 
following  requirements  shall  hold  for  all  accesses  between  all  subjects 
external  to  the  TCB  and  all  objects  directly  or  indirectly  accessible  by 
these  subjects:  A  subject  can  read  an  object  only  if  the  hierarchical 


1  The  hierarchical  classification  component  in  human-readable  sensitivity  labels  shall  be  equal  to  the  greatest 
hierarchical  classification  of  any  of  the  information  in  the  output  that  the  labels  refer  to;  the 
non-hierarchical  category  component  shall  include  all  of  the  non-hierarchical  categories  of  the  information 
in  the  output  the  labels  refer  to,  but  no  other  non-hierarchical  categories. 
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classification  in  the  subject's  security  level  is  greater  than  or  equal  to  the 
hierarchical  classification  in  the  object's  security  level  and  the 
non-hierarchical  categories  in  the  subject's  security  level  include  all  the 
non-hierarchical  categories  in  the  object's  security  level.  A  subject  can 
write  an  object  only  if  the  hierarchical  classification  in  the  subject's 
security  level  is  less  than  or  equal  to  the  hierarchical  classification  in  the 
object's  security  level  and  all  the  non-hierarchical  categories  in  the 
subject's  security  level  are  included  in  the  non-hierarchical  categories  in 
the  object's  security  level. 


3.3.2  Accountability 

3.3.2. 1  Identification  and  Authentication 

The  TCB  shall  require  users  to  identify  themselves  to  it  before  beginning 
to  perform  any  other  actions  that  the  TCB  is  expected  to  mediate. 
Furthermore,  the  TCB  shall  maintain  authentication  data  that  includes 
information  for  verifying  the  identity  of  individual  users  (e.g.,  passwords) 
as  well  as  information  for  determining  the  clearance  and  authorizations 
of  individual  users.  This  data  shall  be  used  by  the  TCB  to  authenticate 
the  user's  identity  and  to  determine  the  security  level  and  authorizations 
of  subjects  that  may  be  created  to  act  on  behalf  of  the  individual  user. 
The  TCB  shall  protect  authentication  data  so  that  it  cannot  be  accessed 
by  any  unauthorized  user.  The  TCB  shall  be  able  to  enforce  individual 
accountability  by  providing  the  capability  to  uniquely  identify  each 
individual  A  DP  system  user.  The  TCB  shall  also  provide  the  capability 
of  associating  this  identity  with  all  auditable  actions  taken  by  that 
individual. 

3. 3. 2. 1.1  Trusted  Path 

The  TCB  shall  support  a  trusted  communication  path  between 
itself  and  users  for  use  when  a  positive  TCB-to-user  connection  is 
required  (e.g.,  login,  change  subject  security  level).  Communica¬ 
tions  via  this  trusted  path  shall  be  activated  exclusively  by  a  user 

or  the  TCB  and  shall  be  logically  isolated  and  unmistakably 
distinguishable  from  other  paths. 

3. 3. 2. 2  Audit 

The  TCB  shall  be  able  to  create,  maintain,  and  protect  from  modification 
or  unauthorized  access  or  destruction  an  audit  trail  of  accesses  to  the 
objects  it  protects.  The  audit  data  shall  be  protected  by  the  TCB  so  that 
read  access  to  it  is  limited  to  those  who  are  authorized  for  audit  data. 
The  TCB  shall  be  able  to  record  the  following  types  of  events:  use  of 
identification  and  authentication  mechanisms,  introduction  of  objects 
into  a  user's  address  space  (e.g.,  file  open,  program  initiation),  deletion 
of  objects,  and  actions  taken  by  computer  operators  and  system 
administrators  and/or  system  security  officers.  The  TCB  shall  also  be 
able  to  audit  any  override  of  human-readable  output  markings.  For  each 
recorded  event,  the  audit  record  shall  identify:  date  and  time  of  the 
event,  user,  type  of  event,  and  success  or  failure  of  the  event.  For 
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identification/authentication  events  the  origin  of  request  (e.g.,  terminal 
ID)  shall  be  included  in  the  audit  record.  For  events  that  introduce  an 
object  into  a  user's  address  space  and  for  object  deletion  events  the 
audit  record  shall  include  the  name  of  the  object  and  the  object's 
security  level.  The  ADP  system  administrator  shall  be  able  to  selectively 
audit  the  actions  of  any  one  or  more  users  based  on  individual  identity 
and/or  object  security  level.  The  TCB  shall  be  able  to  audit  the 
identified  events  that  may  be  used  in  the  exploitation  of  covert  storage 
channels.  The  TCB  shall  contain  a  mechanism  that  is  able  to  monitor 
the  occurrence  or  accumulation  of  security  auditable  events  that  may 
indicate  an  imminent  violation  of  security  policy.  This  mechanism 
shall  be  able  to  immediately  notify  the  security  administrator  when 
thresholds  are  exceeded. 


3.3.3  Assurance 

3 . 3 . 3 . 1  Operational  Assurance 

3 . 3 . 3 . 1 . 1  System  Architecture 

The  TCB  shall  maintain  a  domain  for  its  own  execution  that 
protects  it  from  external  interference  or  tampering  (e.g.,  by 
modification  of  its  code  or  data  structures).  The  TCB  shall 
maintain  process  isolation  through  the  provision  of  distinct  address 
spaces  under  its  control.  The  TCB  shall  be  internally  structured 
into  well-defined  largely  independent  modules.  It  shall  make 
effective  use  of  available  hardware  to  separate  those  elements  that 
are  protection-critical  from  those  that  are  not.  The  TCB  modules 
shall  be  designed  such  that  the  principle  of  least  privilege  is 
enforced.  Features  in  hardware,  such  as  segmentation,  shall  be 
used  to  support  logically  distinct  storage  objects  with  separate 
attributes  (namely:  readable,  writeable).  The  user  interface  to  the 
TCB  shall  be  completely  defined  and  all  elements  of  the  TCB 
identified.  The  TCB  shall  be  designed  and  structured  to  use  a 
complete,  conceptually  simple  protection  mechanism  with 
precisely  defined  semantics.  This  mechanism  shall  play  a 
central  role  in  enforcing  the  internal  structuring  of  the  TCB  and 
the  system.  The  TCB  shall  incorporate  significant  use  of 
layering,  abstraction  and  data  hiding.  Significant  system 
engineering  shall  be  directed  toward  minimizing  the  complexity 
of  the  TCB  and  excluding  from  the  TCB  modules  that  are  not 
protection-critical. 

3 . 3 . 3 . 1 . 2  System  Integrity 

Hardware  and/or  software  features  shall  be  provided  that  can  be 
used  to  periodically  validate  the  correct  operation  of  the  on-site 
hardware  and  firmware  elements  of  the  TCB. 
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3 . 3 . 3 . 1 . 3  Covert  Channel  Analysis 


The  system  developer  shall  conduct  a  thorough  search  for  covert 
channels  and  make  a  determination  (either  by  actual  measurement 
or  by  engineering  estimation)  of  the  maximum  bandwidth  of  each 
identified  channel.  (See  the  Covert  Channels  Guideline  section.) 


3. 3. 3. 1.4  Trusted  Facility  Management 


The  TCB  shall  support  separate  operator  and  administrator 
functions.  The  functions  performed  in  the  role  of  a  security 
administrator  shall  be  identified.  The  ADP  system  administra¬ 
tive  personnel  shall  only  be  able  to  perform  security  administra¬ 
tor  functions  after  taking  a  distinct  auditable  action  to  assume 
the  security  administrator  role  on  the  ADP  system.  Non-secur¬ 
ity  functions  that  can  be  performed  in  the  security  administra¬ 
tion  role  shall  be  limited  strictly  to  those  essential  to 
performing  the  security  role  effectively. 


3 . 3 . 3 . 1 . 5  Trusted  Recovery 


Procedures  and/or  mechanisms  shall  be  provided  to  assure  that, 
after  an  ADP  system  failure  or  other  discontinuity,  recovery 
without  a  protection  compromise  is  obtained. 


3. 3. 3. 2  Life-Cycle  Assurance 

3. 3. 3. 2. 1  Security  Testing 


The  security  mechanisms  of  the  ADP  system  shall  be  tested  and 
found  to  work  as  claimed  in  the  system  documentation.  A  team  of 
individuals  who  thoroughly  understand  the  specific  implementation 
of  the  TCB  shall  subject  its  design  documentation,  source  code, 
and  object  code  to  thorough  analysis  and  testing.  Their  objectives 
shall  be:  to  uncover  all  design  and  implementation  flaws  that 
would  permit  a  subject  external  to  the  TCB  to  read,  change,  or 
delete  data  normally  denied  under  the  mandatory  or  discretionary 
security  policy  enforced  by  the  TCB;  as  well  as  to  assure  that  no 
subject  (without  authorization  to  do  so)  is  able  to  cause  the  TCB 
to  enter  a  state  such  that  it  is  unable  to  respond  to  communica¬ 
tions  initiated  by  other  users.  The  TCB  shall  be  found  resistant 
to  penetration.  All  discovered  flaws  shall  be  corrected  and  the 
TCB  retested  to  demonstrate  that  they  have  been  eliminated  and 
that  new  flaws  have  not  been  introduced.  Testing  shall 
demonstrate  that  the  TCB  implementation  is  consistent  with  the 
descriptive  top-level  specification.  (See  the  Security  Testing 
Guidelines.)  No  design  flaws  and  no  more  than  a  few  correct¬ 
able  implementation  flaws  may  be  found  during  testing  and  there 
shall  be  reasonable  confidence  that  few  remain. 
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3. 3. 3. 2. 2  Design  Specification  and  Verification 

A  formal  model  of  the  security  policy  supported  by  the  TCB  shall 
be  maintained  that  is  proven  consistent  with  its  axioms.  A 
descriptive  top-level  specification  (DTLS)  of  the  TCB  shall  be 
maintained  that  completely  and  accurately  describes  the  TCB  in 
terms  of  exceptions,  error  messages,  and  effects.  It  shall  be 
shown  to  be  an  accurate  description  of  the  TCB  interface.  A 
convincing  argument  shall  be  given  that  the  DTLS  is  consistent 
with  the  model. 

3. 3. 3. 2. 3  Configuration  Management 

During  development  and  maintenance  of  the  TCB,  a  configuration 
management  system  shall  be  in  place  that  maintains  control  of 
changes  to  the  descriptive  top-level  specification,  other  design 
data,  implementation  documentation,  source  code,  the  running 
version  of  the  object  code,  and  test  fixtures  and  documentation. 
The  configuration  management  system  shall  assure  a  consistent 
mapping  among  all  documentation  and  code  associated  with  the 
current  version  of  the  TCB.  Tools  shall  be  provided  for 
generation  of  a  new  version  of  the  TCB  from  source  code.  Also 
available  shall  be  tools  for  comparing  a  newly  generated  version 
with  the  previous  TCB  version  in  order  to  ascertain  that  only  the 
intended  changes  have  been  made  in  the  code  that  will  actually  be 
used  as  the  new  version  of  the  TCB. 


3.3.4  Documentation 

3.3.4. 1  Security  Features  User's  Guide 

A  single  summary,  chapter,  or  manual  in  user  documentation  shall 
describe  the  protection  mechanisms  provided  by  the  TCB,  guidelines  on 
their  use,  and  how  they  interact  with  one  another. 

3. 3. 4. 2  Trusted  Facility  Manual 

A  manual  addressed  to  the  ADP  system  administrator  shall  present 
cautions  about  functions  and  privileges  that  should  be  controlled  when 
running  a  secure  facility.  The  procedures  for  examining  and  maintaining 
the  audit  files  as  well  as  the  detailed  audit  record  structure  for  each  type 
of  audit  event  shall  be  given.  The  manual  shall  describe  the  operator  and 
administrator  functions  related  to  security,  to  include  changing  the 
security  characteristics  of  a  user.  It  shall  provide  guidelines  on  the 
consistent  and  effective  use  of  the  protection  features  of  the  system,  how 
they  interact,  how  to  securely  generate  a  new  TCB,  and  facility 
procedures,  warnings,  and  privileges  that  need  to  be  controlled  in  order 
to  operate  the  facility  in  a  secure  manner.  The  TCB  modules  that 
contain  the  reference  validation  mechanism  shall  be  identified.  The 
procedures  for  secure  generation  of  a  new  TCB  from  source  after 
modification  of  any  modules  in  the  TCB  shall  be  described.  It  shall 
include  the  procedures  to  ensure  that  the  system  is  initially  started  in 
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a  secure  manner.  Procedures  shall  also  be  included  to  resume  secure 
system  operation  after  any  lapse  in  system  operation. 

3. 3. 4. 3  Test  Documentation 

The  system  developer  shall  provide  to  the  evaluators  a  document  that 
describes  the  test  plan  and  results  of  the  security  mechanisms'  functional 
testing.  It  shall  include  results  of  testing  the  effectiveness  of  the 
methods  used  to  reduce  covert  channel  bandwidths. 

3. 3.4.4  Design  Documentation 

Documentation  shall  be  available  that  provides  a  description  of  the 
manufacturer's  philosophy  of  protection  and  an  explanation  of  how  this 
philosophy  is  translated  into  the  TCB.  The  interfaces  between  the  TCB 
modules  shall  be  described.  A  formal  description  of  the  security  policy 
model  enforced  by  the  TCB  shall  be  available  and  proven  that  it  is 
sufficient  to  enforce  the  security  policy.  The  specific  TCB  protection 
mechanisms  shall  be  identified  and  an  explanation  given  to  show  that 
they  satisfy  the  model.  The  descriptive  top-level  specification  (DTLS) 
shall  be  shown  to  be  an  accurate  description  of  the  TCB  interface. 
Documentation  shall  describe  how  the  TCB  implements  the  reference 
monitor  concept  and  give  an  explanation  why  it  is  tamperproof,  cannot 
be  bypassed,  and  is  correctly  implemented.  The  TCB  implementation 
(i.e.,  in  hardware,  firmware,  and  software)  shall  be  informally  shown 
to  be  consistent  with  the  DTLS.  The  elements  of  the  DTLS  shall  be 
shown,  using  informal  techniques,  to  correspond  to  the  elements  of  the 
TCB.  Documentation  shall  describe  how  the  TCB  is  structured  to 
facilitate  testing  and  to  enforce  least  privilege.  This  documentation  shall 
also  present  the  results  of  the  covert  channel  analysis  and  the  tradeoffs 
involved  in  restricting  the  channels.  All  auditable  events  that  may  be 
used  in  the  exploitation  of  known  covert  storage  channels  shall  be 
identified.  The  bandwidths  of  known  covert  storage  channels,  the  use  of 
which  is  not  detectable  by  the  auditing  mechanisms,  shall  be  provided. 
(See  the  Covert  Channel  Guideline  section.) 
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4.0  DIVISION  A:  VERIFIED  PROTECTION 


This  division  is  characterized  by  the  use  of  formal  security  verification  methods  to  assure 
that  the  mandatory  and  discretionary  security  controls  employed  in  the  system  can 
effectively  protect  classified  or  other  sensitive  information  stored  or  processed  by  the 
system.  Extensive  documentation  is  required  to  demonstrate  that  the  TCB  meets  the 
security  requirements  in  all  aspects  of  design,  development  and  implementation. 
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4.1  CLASS  (A  1):  VERIFIED  DESIGN 


P 


Systems  in  class  (Al)  are  functionally  equivalent  to  those  in  class  <B3)  in  that  no 
additional  architectural  features  or  policy  requirements  are  added.  The  distinguishing 
feature  of  systems  in  this  class  is  the  analysis  derived  from  formal  design  specification 
and  verification  techniques  and  the  resulting  high  degree  of  assurance  that  the  TCB  is 
correctly  implemented.  This  assurance  is  developmental  in  nature,  starting  with  a  formal 
model  of  the  security  policy  and  a  formal  top-level  specification  (FTLS)  of  the  design. 
Independent  of  the  particular  specification  language  or  verification  system  used,  there  are 
five  important  criteria  for  class  (All  design  verification: 

*  A  formal  model  of  the  security  policy  must  be  clearly  identified  and 
documented,  including  a  mathematical  proof  that  the  model  is  consistent  with  its 
axioms  and  is  sufficient  to  support  the  security  policy. 

*  An  FTLS  must  be  produced  that  includes  abstract  definitions  of  the  functions 
the  TCB  performs  and  of  the  hardware  and/or  firmware  mechanisms  that  are 
used  to  support  separate  execution  domains. 

*  The  FTLS  of  the  TCB  must  be  shown  to  be  consistent  with  the  model  by  formal 
techniques  where  possible  (i.  e. ,  where  verification  tools  exist )  and  in formal  ones 
otherwise. 

*  The  TCB  implementation  (i.e.,  in  hardware,  firmware,  and  software)  must  be 
informally  shown  to  be  consistent  with  the  FTLS.  The  elements  of  the  FTLS 
must  be  shown,  using  informal  techniques,  to  correspond  to  the  elements  of  the 
TCB.  The  FTLS  must  express  the  unified  protection  mechanism  required  to 
satisfy  the  security  policy,  and  it  is  the  elements  of  this  protection  mechanism 
that  are  mapped  to  the  elements  of  the  TCB. 

*  Formal  analysis  techniques  must  be  used  to  identify  and  analyze  covert  channels. 
Informal  techniques  may  be  used  to  identify  covert  timing  channels.  The 
continued  existence  of  identified  covert  channels  in  the  system  must  be  justified. 

In  keeping  with  the  extensive  design  and  development  analysis  of  the  TCB  required  of 
systems  in  class  <A1),  more  stringent  configuration  management  is  required  and 
procedures  are  established  for  securely  distributing  the  system  to  sites.  A  system  security 
administrator  is  supported. 

The  following  are  minimal  requirements  for  systems  assigned  a  class  (A  I)  rating: 
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4.1.1  Security  Policy 

4. 1 . 1 . 1  Discretionary  Access  Control 

The  TCB  shall  define  and  control  access  between  named  users  and  named 
objects  (e.g.,  files  and  programs)  in  the  ADP  system.  The  enforcement 
mechanism  (e.g.,  access  control  lists)  shall  allow  users  to  specify  and 
control  sharing  of  those  objects.  The  discretionary  access  control 
mechanism  shall,  either  by  explicit  user  action  or  by  default,  provide  that 
objects  are  protected  from  unauthorized  access.  These  access  controls 
shall  be  capable  of  specifying,  for  each  named  object,  a  list  of  named 
individuals  and  a  list  of  groups  of  named  individuals  with  their  respective 
modes  of  access  to  that  object.  Furthermore,  for  each  such  named 
object,  it  shall  be  possible  to  specify  a  list  of  named  individuals  and  a  list 
of  groups  of  named  individuals  for  which  no  access  to  the  object  is  to  be 
given.  Access  permission  to  an  object  by  users  not  already  possessing 
access  permission  shall  only  be  assigned  by  authorized  users. 

4. 1.1. 2  Object  Reuse 

When  a  storage  object  is  initially  assigned,  allocated,  or  reallocated  to  a 
subject  from  the  TCB's  pool  of  unused  storage  objects,  the  TCB  shall 
assure  that  the  object  contains  no  data  for  which  the  subject  is  not 
authorized. 

4. 1.1.3  Labels 

Sensitivity  labels  associated  with  each  ADP  system  resource  (e.g., 
subject,  storage  object)  that  is  directly  or  indirectly  accessible  by 
subjects  external  to  the  TCB  shall  be  maintained  by  the  TCB.  These 
labels  shall  be  used  as  the  basis  for  mandatory  access  control  decisions. 
In  order  to  import  non-labeled  data,  the  TCB  shall  request  and  receive 
from  an  authorized  user  the  security  level  of  the  data,  and  all  such 
actions  shall  be  auditable  by  the  TCB. 

4. 1 . 1 .3. 1  Label  Integrity 

Sensitivity  labels  shall  accurately  represent  security  levels  of  the 
specific  subjects  or  objects  with  which  they  are  associated.  When 
exported  by  the  TCB,  sensitivity  labels  shall  accurately  and 
unambiguously  represent  the  internal  labels  and  shall  be  associated 
with  the  information  being  exported. 

4. 1 . 1 .3.2  Exportation  of  Labeled  Information 

The  TCB  shall  designate  each  communication  channel  and  I/O 
device  as  either  single-level  or  multilevel.  Any  change  in  this 
designation  shall  be  done  manually  and  shall  be  auditable  by  the 
TCB.  The  TCB  shall  maintain  and  be  able  to  audit  any  change  in 
the  current  security  level  associated  with  a  single-level  communica¬ 
tion  channel  or  I/O  device. 
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4. 1 . 1 .3.2. 1  Exportation  to  Multilevel  Devices 

When  the  TCB  exports  an  object  to  a  multilevel  I/O  device, 
the  sensitivity  label  associated  with  that  object  shall  also  be 
exported  and  shall  reside  on  the  same  physical  medium  as 
the  exported  information  and  shall  be  in  the  same  form  (i.e. , 
machine-readable  or  human-readable  form).  When  the  TCB 
exports  or  imports  an  object  over  a  multilevel  communica¬ 
tion  channel,  the  protocol  used  on  that  channel  shall 
provide  for  the  unambiguous  pairing  between  the  sensitivity 
labels  and  the  associated  information  that  is  sent  or 
received. 

4. 1 . 1 .3.2.2  Exportation  to  Single-Level  Devices 

Single-level  I/O  devices  and  single-level  communication 
channels  are  not  required  to  maintain  the  sensitivity  labels 
of  the  information  they  process.  However,  the  TCB  shall 
include  a  mechanism  by  which  the  TCB  and  an  authorized 
user  reliably  communicate  to  designate  the  single  security 
level  of  information  imported  or  exported  via  single-level 
communication  channels  or  I/O  devices. 

4. 1 . 1 .3.2.3  Labeling  Human-Readable  Output 

The  ADP  system  administrator  shall  be  able  to  specify  the 
printable  label  names  associated  with  exported  sensitivity 
labels.  The  TCB  shall  mark  the  beginning  and  end  of  all 
human-readable,  paged,  hardcopy  output  (e.g.,  line  printer 
output)  with  human-readable  sensitivity  labels  that  properly1 
represent  the  sensitivity  of  the  output.  The  TCB  shall,  by 
default,  mark  the  top  and  bottom  of  each  page  of  human- 
readable,  paged,  hardcopy  output  (e.g.,  line  printer  output) 
with  human-readable  sensitivity  labels  that  properly1 
represent  the  overall  sensitivity  of  the  output  or  that 
properly1  represent  the  sensitivity  of  the  information  on  the 
page.  The  TCB  shall,  by  default  and  in  an  appropriate 
manner,  mark  other  forms  of  human-readable  output  (e.g., 
maps,  graphics)  with  human-readable  sensitivity  labels  that 
properly1  represent  the  sensitivity  of  the  output.  Any 
override  of  these  marking  defaults  shall  be  auditable  by  the 
TCB. 

4. 1 . 1 .3.3  Subject  Sensitivity  Labels 

The  TCB  shall  immediately  notify  a  terminal  user  of  each  change 
in  the  security  level  associated  with  that  user  during  an  interactive 
session.  A  terminal  user  shall  be  able  to  query  the  TCB  as  desired 
for  a  display  of  the  subject's  complete  sensitivity  label. 


1  The  hierarchical  classification  component  in  human-readable  sensitivity  labels  shall  be  equal  to  the  greatest 
hierarchical  classification  of  any  of  the  information  in  the  output  that  the  labels  refer  to;  the 
non-hierarchical  category  component  shall  include  all  of  the  non-hierarchical  categories  of  the  information 
in  the  output  the  labels  refer  to,  but  no  other  non-hierarchical  categories. 
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4 . 1 . 1 . 3 . 4  Device  Labels 

The  TCB  shall  support  the  assignment  of  minimum  and  maximum 
security  levels  to  all  attached  physical  devices.  These  security 
levels  shall  be  used  by  the  TCB  to  enforce  constraints  imposed  by 
the  physical  environments  in  which  the  devices  are  located. 

4. 1 . 1 .4  Mandatory  Access  Control 

The  TCB  shall  enforce  a  mandatory  access  control  policy  over  all 
resources  (i.e.,  subjects,  storage  objects,  and  I/O  devices)  that  are 
directly  or  indirectly  accessible  by  subjects  external  to  the  TCB.  These 
subjects  and  objects  shall  be  assigned  sensitivity  labels  that  are  a 
combination  of  hierarchical  classification  levels  and  non-hierarchical 
categories,  and  the  labels  shall  be  used  as  the  basis  for  mandatory  access 
control  decisions.  The  TCB  shall  be  able  to  support  two  or  more  such 
security  levels.  (See  the  Mandatory  Access  Control  guidelines.)  The 
following  requirements  shall  hold  for  all  accesses  between  all  subjects 
external  to  the  TCB  and  all  objects  directly  or  indirectly  accessible  by 
these  subjects:  A  subject  can  read  an  object  only  if  the  hierarchical 
classification  in  the  subject's  security  level  is  greater  than  or  equal  to  the 
hierarchical  classification  in  the  object's  security  level  and  the 
non-hierarchical  categories  in  the  subject's  security  level  include  all  the 
non-hierarchical  categories  in  the  object's  security  level.  A  subject  can 
write  an  object  only  if  the  hierarchical  classification  in  the  subject's 
security  level  is  less  than  or  equal  to  the  hierarchical  classification  in  the 
object's  security  level  and  all  the  non-hierarchical  categories  in  the 
subject's  security  level  are  included  in  the  non-hierarchical  categories  in 
the  object's  security  level. 


4.1.2  Accountability 

4. 1 .2. 1  Identification  and  Authentication 

The  TCB  shall  require  users  to  identify  themselves  to  it  before  beginning 
to  perform  any  other  actions  that  the  TCB  is  expected  to  mediate. 
Furthermore,  the  TCB  shall  maintain  authentication  data  that  includes 
information  for  verifying  the  identity  of  individual  users  (e.g.,  passwords) 
as  well  as  information  for  determining  the  clearance  and  authorizations 
of  individual  users.  This  data  shall  be  used  by  the  TCB  to  authenticate 
the  user's  identity  and  to  determine  the  security  level  and  authorizations 
of  subjects  that  may  be  created  to  act  on  behalf  of  the  individual  user. 
The  TCB  shall  protect  authentication  data  so  that  it  cannot  be  accessed 
by  any  unauthorized  user.  The  TCB  shall  be  able  to  enforce  individual 
accountability  by  providing  the  capability  to  uniquely  identify  each 
individual  ADP  system  user.  The  TCB  shall  also  provide  the  capability 
of  associating  this  identity  with  all  auditable  actions  taken  by  that 
individual. 
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4. 1.2. 1.1  Trusted  Path 

The  TCB  shall  support  a  trusted  communication  path  between 
itself  and  users  for  use  when  a  positive  TCB-to-user  connection  is 
required  (e.g.,  login,  change  subject  security  level).  Communica¬ 
tions  via  this  trusted  path  shall  be  activated  exclusively  by  a  user 
or  the  TCB  and  shall  be  logically  isolated  and  unmistakably 
distinguishable  from  other  paths. 


4. 1.2.2  Audit 

The  TCB  shall  be  able  to  create,  maintain,  and  protect  from  modification 
or  unauthorized  access  or  destruction  an  audit  trail  of  accesses  to  the 
objects  it  protects.  The  audit  data  shall  be  protected  by  the  TCB  so  that 
read  access  to  it  is  limited  to  those  who  are  authorized  for  audit  data. 
The  TCB  shall  be  able  to  record  the  following  types  of  events:  use  of 
identification  and  authentication  mechanisms,  introduction  of  objects 
into  a  user's  address  space  (e.g.,  file  open,  program  initiation),  deletion 
of  objects,  and  actions  taken  by  computer  operators  and  system 
administrators  and/or  system  security  officers.  The  TCB  shall  also  be 
able  to  audit  any  override  of  human-readable  output  markings.  For  each 
recorded  event,  the  audit  record  shall  identify:  date  and  time  of  the 
event,  user,  type  of  event,  and  success  or  failure  of  the  event.  For 
identification/authentication  events  the  origin  of  request  (e.g.,  terminal 
ID)  shall  be  included  in  the  audit  record.  For  events  that  introduce  an 
object  into  a  user's  address  space  and  for  object  deletion  events  the 
audit  record  shall  include  the  name  of  the  object  and  the  object's 
security  level.  The  A  DP  system  administrator  shall  be  able  to  selectively 
audit  the  actions  of  any  one  or  more  users  based  on  individual  identity 
and/or  object  security  level.  The  TCB  shall  be  able  to  audit  the 
identified  events  that  may  be  used  in  the  exploitation  of  covert  storage 
channels.  The  TCB  shall  contain  a  mechanism  that  is  able  to  monitor 
the  occurrence  or  accumulation  of  security  auditable  events  that  may 
indicate  an  imminent  violation  of  security  policy.  This  mechanism  shall 
be  able  to  immediately  notify  the  security  administrator  when  thresholds 
are  exceeded. 


4.1.3  Assurance 

4 . 1 . 3 . 1  Operational  Assurance 

4. 1 .3. 1 . 1  System  Architecture 

The  TCB  shall  maintain  a  domain  for  its  own  execution  that 
protects  it  from  external  interference  or  tampering  (e.g.,  by 
modification  of  its  code  or  data  structures).  The  TCB  shall 
maintain  process  isolation  through  the  provision  of  distinct  address 
spaces  under  its  control.  The  TCB  shall  be  internally  structured 
into  well-defined  largely  independent  modules.  It  shall  make 
effective  use  of  available  hardware  to  separate  those  elements  that 
are  protection-critical  from  those  that  are  not.  The  TCB  modules 
shall  be  designed  such  that  the  principle  of  least  privilege  is 
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enforced.  Features  in  hardware,  such  as  segmentation,  shall  be 
used  to  support  logically  distinct  storage  objects  with  separate 
attributes  (namely:  readable,  writeable).  The  user  interface  to  the 
TCB  shall  be  completely  defined  and  all  elements  of  the  TCB 
identified.  The  TCB  shall  be  designed  and  structured  to  use  a 
complete,  conceptually  simple  protection  mechanism  with 
precisely  defined  semantics.  This  mechanism  shall  play  a  central 
role  in  enforcing  the  internal  structuring  of  the  TCB  and  the 
system.  The  TCB  shall  incorporate  significant  use  of  layering, 
abstraction  and  data  hiding.  Significant  system  engineering  shall 
be  directed  toward  minimizing  the  complexity  of  the  TCB  and 
excluding  from  the  TCB  modules  that  are  not  protection-critical. 

4 . 1 . 3 . 1 . 2  System  Integrity 

Hardware  and/or  software  features  shall  be  provided  that  can  be 
used  to  periodically  validate  the  correct  operation  of  the  on-site 
hardware  and  firmware  elements  of  the  TCB. 

4. 1 .3. 1 .3  Covert  Channel  Analysis 

The  system  developer  shall  conduct  a  thorough  search  for  covert 
channels  and  make  a  determination  (either  by  actual  measurement 
or  by  engineering  estimation)  of  the  maximum  bandwidth  of  each 
identified  channel.  (See  the  Covert  Channels  Guideline  section.) 

Formal  methods  shall  be  used  in  the  analysis. 

4. 1.3. 1.4  Trusted  Facility  Management 

The  TCB  shall  support  separate  operator  and  administrator 
functions.  The  functions  performed  in  the  role  of  a  security 
administrator  shall  be  identified.  The  ADP  system  administrative 
personnel  shall  only  be  able  to  perform  security  administrator 
functions  after  taking  a  distinct  auditable  action  to  assume  the 
security  administrator  role  on  the  ADP  system.  Non-security 
functions  that  can  be  performed  in  the  security  administration  role 
shall  be  limited  strictly  to  those  essential  to  performing  the 
security  role  effectively. 

4 . 1 . 3 . 1 . 5  Trusted  Recovery 

Procedures  and/or  mechanisms  shall  be  provided  to  assure  that, 
after  an  ADP  system  failure  or  other  discontinuity,  recovery 
without  a  protection  compromise  is  obtained. 

4. 1 . 3 . 2  Life-Cycle  Assurance 

4. 1.3. 2.1  Security  Testing 

The  security  mechanisms  of  the  ADP  system  shall  be  tested  and 
found  to  work  as  claimed  in  the  system  documentation.  A  team  of 
individuals  who  thoroughly  understand  the  specific  implementation 
of  the  TCB  shall  subject  its  design  documentation,  source  code, 
and  object  code  to  thorough  analysis  and  testing.  Their  objectives 
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shall  be:  to  uncover  all  design  and  implementation  flaws  that 
would  permit  a  subject  external  to  the  TCB  to  read,  change,  or 
delete  data  normally  denied  under  the  mandatory  or  discretionary 
security  policy  enforced  by  the  TCB;  as  well  as  to  assure  that  no 
subject  (without  authorization  to  do  so)  is  able  to  cause  the  TCB 
to  enter  a  state  such  that  it  is  unable  to  respond  to  communica¬ 
tions  initiated  by  other  users.  The  TCB  shall  be  found  resistant  to 
penetration.  All  discovered  flaws  shall  be  corrected  and  the  TCB 
retested  to  demonstrate  that  they  have  been  eliminated  and  that 
new  flaws  have  not  been  introduced.  Testing  shall  demonstrate 
that  the  TCB  implementation  is  consistent  with  the  formal 
top-level  specification.  (See  the  Security  Testing  Guidelines.)  No 
design  flaws  and  no  more  than  a  few  correctable  implementation 
flaws  may  be  found  during  testing  and  there  shall  be  reasonable 
confidence  that  few  remain.  Manual  or  other  mapping  of  the 
FTLS  to  the  source  code  may  form  a  basis  for  penetration 
testing. 

4. 1 .3.2.2  Design  Specification  and  Verification 

A  formal  model  of  the  security  policy  supported  by  the  TCB  shall 
be  maintained  that  is  proven  consistent  with  its  axioms.  A 
descriptive  top-level  specification  (DTLS)  of  the  TCB  shall  be 
maintained  that  completely  and  accurately  describes  the  TCB  in 
terms  of  exceptions,  error  messages,  and  effects.  A  formal 
top-level  specification  (FTLS)  of  the  TCB  shall  be  maintained 
that  accurately  describes  the  TCB  in  terms  of  exceptions,  error 
messages,  and  effects.  The  DTLS  and  FTLS  shall  include  those 
components  of  the  TCB  that  are  implemented  as  hardware 
and/or  firmware  if  their  properties  are  visible  at  the  TCB 
interface.  The  FTLS  shall  be  shown  to  be  an  accurate 
description  of  the  TCB  interface.  A  convincing  argument  shall  be 
given  that  the  DTLS  is  consistent  with  the  model  and  a 
combination  of  formal  and  informal  techniques  shall  be  used  to 
show  that  the  FTLS  is  consistent  with  the  model.  This 
verification  evidence  shall  be  consistent  with  that  provided 
within  the  state-of-the-art  of  the  particular  Computer  Security 
Center-endorsed  formal  specification  and  verification  system 
used.  Manual  or  other  mapping  of  the  FTLS  to  the  TCB  source 
code  shall  be  performed  to  provide  evidence  of  correct 
implementation. 

4 . 1 . 3 . 2 . 3  Configuration  Management 

During  the  entire  life-cycle,  i.e.,  during  the  design,  development, 

and  maintenance  of  the  TCB,  a  configuration  management  system 
shall  be  in  place  for  all  security-relevant  hardware,  firmware, 
and  software  that  maintains  control  of  changes  to  the  formal 
model,  the  descriptive  and  formal  top-level  specifications,  other 
design  data,  implementation  documentation,  source  code,  the 
running  version  of  the  object  code,  and  test  fixtures  and 
documentation.  The  configuration  management  system  shall 
assure  a  consistent  mapping  among  all  documentation  and  code 
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associated  with  the  current  version  of  the  TCB.  Tools  shall  be 
provided  for  generation  of  a  new  version  of  the  TCB  from  source 
code.  Also  available  shall  be  tools,  maintained  under  strict 
configuration  control,  for  comparing  a  newly  generated  version 
with  the  previous  TCB  version  in  order  to  ascertain  that  only  the 
intended  changes  have  been  made  in  the  code  that  will  actually  be 
used  as  the  new  version  of  the  TCB.  A  combination  of  technical, 
physical,  and  procedural  safeguards  shall  be  used  to  protect 
from  unauthorized  modification  or  destruction  the  master  copy 
or  copies  of  all  material  used  to  generate  the  TCB. 

4. 1.3. 2. 4  Trusted  Distribution 

A  trusted  ADP  system  control  and  distribution  facility  shall  be 
provided  for  maintaining  the  integrity  of  the  mapping  between 
the  master  data  describing  the  current  version  of  the  TCB  and 
the  on-site  master  copy  of  the  code  for  the  current  version. 
Procedures  (e.g.,  site  security  acceptance  testing)  shall  exist  for 
assuring  that  the  TCB  software,  firmware,  and  hardware 
updates  distributed  to  a  customer  are  exactly  as  specified  by  the 
master  copies. 


4.1.4  Documentation 

4. 1.4.1  Security  Features  User's  Guide 

A  single  summary,  chapter,  or  manual  in  user  documentation  shall 
describe  the  protection  mechanisms  provided  by  the  TCB,  guidelines  on 
their  use,  and  how  they  interact  with  one  another. 

4. 1.4. 2  Trusted  Facility  Manual 

A  manual  addressed  to  the  ADP  system  administrator  shall  present 
cautions  about  functions  and  privileges  that  should  be  controlled  when 
running  a  secure  facility.  The  procedures  for  examining  and  maintaining 
the  audit  files  as  well  as  the  detailed  audit  record  structure  for  each  type 
of  audit  event  shall  be  given.  The  manual  shall  describe  the  operator  and 
administrator  functions  related  to  security,  to  include  changing  the 
security  characteristics  of  a  user.  It  shall  provide  guidelines  on  the 
consistent  and  effective  use  of  the  protection  features  of  the  system,  how 
they  interact,  how  to  securely  generate  a  new  TCB,  and  facility 
procedures,  warnings,  and  privileges  that  need  to  be  controlled  in  order 
to  operate  the  facility  in  a  secure  manner.  The  TCB  modules  that 
contain  the  reference  validation  mechanism  shall  be  identified.  The 
procedures  for  secure  generation  of  a  new  TCB  from  source  after 
modification  of  any  modules  in  the  TCB  shall  be  described.  It  shall 
include  the  procedures  to  ensure  that  the  system  is  initially  started  in  a 
secure  manner.  Procedures  shall  also  be  included  to  resume  secure 
system  operation  after  any  lapse  in  system  operation. 
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4. 1.4. 3  Test  Documentation 

The  system  developer  shall  provide  to  the  evaluators  a  document  that 
describes  the  test  plan  and  results  of  the  security  mechanisms'  functional 
testing.  It  shall  include  results  of  testing  the  effectiveness  of  the 
methods  used  to  reduce  covert  channel  bandwidths.  The  results  of  the 
mapping  between  the  formal  top-level  specification  and  the  TCB 
source  code  shall  be  given. 

4. 1.4.4  Design  Documentation 

Documentation  shall  be  available  that  provides  a  description  of  the 
manufacturer's  philosophy  of  protection  and  an  explanation  of  how  this 
philosophy  is  translated  into  the  TCB.  The  interfaces  between  the  TCB 
modules  shall  be  described.  A  formal  description  of  the  security  policy 
model  enforced  by  the  TCB  shall  be  available  and  proven  that  it  is 
sufficient  to  enforce  the  security  policy.  The  specific  TCB  protection 
mechanisms  shall  be  identified  and  an  explanation  given  to  show  that 
they  satisfy  the  model.  The  descriptive  top-level  specification  (DTLS) 
shall  be  shown  to  be  an  accurate  description  of  the  TCB  interface. 
Documentation  shall  describe  how  the  TCB  implements  the  reference 
monitor  concept  and  give  an  explanation  why  it  is  tamperproof,  cannot 
be  bypassed,  and  is  correctly  implemented.  The  TCB  implementation 
(i.e.,  in  hardware,  firmware,  and  software)  shall  be  informally  shown  to 
be  consistent  with  the  formal  top-level  specification  (FTLS).  The 
elements  of  the  FTLS  shall  be  shown,  using  informal  techniques,  to 
correspond  to  the  elements  of  the  TCB.  Documentation  shall  describe 
how  the  TCB  is  structured  to  facilitate  testing  and  to  enforce  least 
privilege.  This  documentation  shall  also  present  the  results  of  the  covert 
channel  analysis  and  the  tradeoffs  involved  in  restricting  the  channels. 
All  auditable  events  that  may  be  used  in  the  exploitation  of  known  covert 
storage  channels  shall  be  identified.  The  bandwidths  of  known  covert 
storage  channels,  the  use  of  which  is  not  detectable  by  the  auditing 
mechanisms,  shall  be  provided.  (See  the  Covert  Channel  Guideline 
section.)  Hardware,  firmware,  and  software  mechanisms  not  dealt 
with  in  the  FTLS  but  strictly  internal  to  the  TCB  (e.g.,  mapping 
registers,  direct  memory  access  I/O)  shall  be  clearly  described. 
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4.2  BEYOND  CLASS  (A  1) 


Most  of  the  security  enhancements  envisioned  for  systems  that  will  provide  features 
and  assurance  in  addition  to  that  already  provided  by  class  (Al)  systems  are  beyond 
current  technology.  The  discussion  below  is  intended  to  guide  future  work  and  is 
derived  from  research  and  development  activities  already  underway  in  both  the  public 
and  private  sectors.  As  more  and  better  analysis  techniques  are  developed,  the 
requirements  for  these  systems  will  become  more  explicit.  In  the  future,  use  of 
formal  verification  will  be  extended  to  the  source  level  and  covert  timing  channels  will 
be  more  fully  addressed.  At  this  level  the  design  environment  will  become  important 
and  testing  will  be  aided  by  analysis  of  the  formal  top-level  specification. 
Consideration  will  be  given  to  the  correctness  of  the  tools  used  in  TCB  development 
(e.g.,  compilers,  assemblers,  loaders)  and  to  the  correct  functioning  of  the  hardware/ 
firmware  on  which  the  TCB  will  run.  Areas  to  be  addressed  by  systems  beyond  class 
(Al)  include: 

System  Architecture 

A  demonstration  (formal  or  otherwise)  must  be  given  showing  that  requirements  of 
self-protection  and  completeness  for  reference  monitors  have  been  implemented  in  the 
TCB. 

Security  Testing 

Although  beyond  the  current  state-of-the-art,  it  is  envisioned  that  some  test-case 
generation  will  be  done  automatically  from  the  formal  top-level  specification  or 
formal  lower-level  specifications. 

Formal  Specification  and  Verification 

The  TCB  must  be  verified  down  to  the  source  code  level,  using  formal  verification 
methods  where  feasible.  Formal  verification  of  the  source  code  of  the  security¬ 
relevant  portions  of  an  operating  system  has  proven  to  be  a  difficult  task.  Two 
important  considerations  are  the  choice  of  a  high-level  language  whose  semantics  can 
be  fully  and  formally  expressed,  and  a  careful  mapping,  through  successive  stages,  of 
the  abstract  formal  design  to  a  formalization  of  the  implementation  in  low-level 
specifications.  Experience  has  shown  that  only  when  the  lowest  level  specifications 
closely  correspond  to  the  actual  code  can  code  proofs  be  successfully  accomplished. 

Trusted  Design  Environment 

The  TCB  must  be  designed  in  a  trusted  facility  with  only  trusted  (cleared)  personnel. 
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5.0  CONTROL  OBJECTIVES  FOR  TRUSTED 
COMPUTER  SYSTEMS 


The  criteria  are  divided  within  each  class  into  groups  of  requirements.  These  groupings 
were  developed  to  assure  that  three  basic  control  objectives  for  computer  security  are 
satisfied  and  not  overlooked.  These  control  objectives  deal  with: 

*  Security  Policy 

*  Accountability 

*  Assurance 

This  section  provides  a  discussion  of  these  general  control  objectives  and  their  implication 
in  terms  of  designing  trusted  systems. 
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5.1  A  Need  for  Consensus 

A  major  goal  of  the  DoD  Computer  Security  Center  is  to  encourage  the  Computer 
Industry  to  develop  trusted  computer  systems  and  products,  making  them  widely 
available  in  the  commercial  market  place.  Achievement  of  this  goal  will  require 
recognition  and  articulation  by  both  the  public  and  private  sectors  of  a  need  and 
demand  for  such  products. 

As  described  in  the  introduction  to  this  document,  efforts  to  define  the  problems  and 
develop  solutions  associated  with  processing  nationally  sensitive  information,  as  well 
as  other  sensitive  data  such  as  financial,  medical,  and  personnel  information  used  by 
the  National  Security  Establishment,  have  been  underway  for  a  number  of  years. 
The  criteria,  as  described  in  Part  I,  represent  the  culmination  of  these  efforts  and 
describe  basic  requirements  for  building  trusted  computer  systems.  To  date, 
however,  these  systems  have  been  viewed  by  many  as  only  satisfying  National 
Security  needs.  As  long  as  this  perception  continues  the  consensus  needed  to 
motivate  manufacture  of  trusted  systems  will  be  lacking. 

The  purpose  of  this  section  is  to  describe,  in  some  detail,  the  fundamental  control 
objectives  that  lay  the  foundations  for  requirements  delineated  in  the  criteria.  The 
goal  is  to  explain  the  foundations  so  that  those  outside  the  National  Security 
Establishment  can  assess  their  universality  and,  by  extension,  the  universal 
applicability  of  the  criteria  requirements  to  processing  all  types  of  sensitive 
applications  whether  they  be  for  National  Security  or  the  private  sector. 


5.2  Definition  and  Usefulness 

The  term  control  objective  refers  to  a  statement  of  intent  with  respect  to  control  over 
some  aspect  of  an  organization's  resources,  or  processes,  or  both.  In  terms  of  a 
computer  system,  control  objectives  provide  a  framework  for  developing  a  strategy 
for  fulfilling  a  set  of  security  requirements  for  any  given  system.  Developed  in 
response  to  generic  vulnerabilities,  such  as  the  need  to  manage  and  handle  sensitive 
data  in  order  to  prevent  compromise,  or  the  need  to  provide  accountability  in  order 
to  detect  fraud,  control  objectives  have  been  identified  as  a  useful  method  of 
expressing  security  goals. [3] 

Examples  of  control  objectives  include  the  three  basic  design  requirements  for 
implementing  the  reference  monitor  concept  discussed  in  Section  6.  They  are: 

The  reference  validation  mechanism  must  be  tamperproof. 

*  The  reference  validation  mechanism  must  always  be  invoked. 

The  reference  validation  mechanism  must  be  small  enough  to  be  subjected  to 
analysis  and  tests,  the  completeness  of  which  can  be  assured.!  I  ] 

5.3  Criteria  Control  Objectives 

The  three  basic  control  objectives  of  the  criteria  are  concerned  with  security  policy, 
accountability,  and  assurance.  The  remainder  of  this  section  provides  a  discussion  of 
these  basic  requirements. 
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5.3.1  Security  Policy 

In  the  most  general  sense,  computer  security  is  concerned  with  controlling  the 
way  in  which  a  computer  can  be  used,  i.e.,  controlling  how  information 
processed  by  it  can  be  accessed  and  manipulated.  However,  at  closer 
examination,  computer  security  can  refer  to  a  number  of  areas.  Symptomatic 
of  this,  FIPS  PUB  39,  Glossary  For  Computer  Systems  Security ,  does  not  have  a 
unique  definition  for  computer  security.!  16]  Instead  there  are  eleven  separate 
definitions  for  security  which  include:  ADP  systems  security,  administrative 
security,  data  security,  etc.  A  common  thread  running  through  these 
definitions  is  the  word  protection.  Further  declarations  of  protection 
requirements  can  be  found  in  DoD  Directive  5200.28  which  describes  an 
acceptable  level  of  protection  for  classified  data  to  be  one  that  will  "assure  that 
systems  which  process,  store,  or  use  classified  data  and  produce  classified 
information  will,  with  reasonable  dependability,  prevent:  a.  Deliberate  or 
inadvertent  access  to  classified  material  by  unauthorized  persons,  and  b: 
Unauthorized  manipulation  of  the  computer  and  its  associated  peripheral 
devices.  "[8] 

In  summary,  protection  requirements  must  be  defined  in  terms  of  the  perceived 
threats,  risks,  and  goals  of  an  organization.  This  is  often  stated  in  terms  of  a 
security  policy.  It  has  been  pointed  out  in  the  literature  that  it  is  external 
laws,  rules,  regulations,  etc.  that  establish  what  access  to  information  is  to  be 
permitted,  independent  of  the  use  of  a  computer.  In  particular,  a  given  system 
can  only  be  said  to  be  secure  with  respect  to  its  enforcement  of  some  specific 
policy. [30]  Thus,  the  control  objective  for  security  policy  is: 


SECURITY  POLICY  CONTROL  OBJECTIVE 

A  statement  of  intent  with  regard  to  control  over  access  to  and 
dissemination  of  information,  to  be  known  as  the  security  policy, 
must  be  precisely  defined  and  implemented  for  each  system  that  is 
used  to  process  sensitive  information.  The  security  policy  must 
accurately  reflect  the  laws,  regulations,  and  general  policies  from 
which  it  is  derived. 


5.3. 1 . 1  Mandatory  Security  Policy 

Where  a  security  policy  is  developed  that  is  to  be  applied  to  control  of 
classified  or  other  specifically  designated  sensitive  information,  the  policy 
must  include  detailed  rules  on  how  to  handle  that  information 
throughout  its  life-cycle.  These  rules  are  a  function  of  the  various 
sensitivity  designations  that  the  information  can  assume  and  the  various 
forms  of  access  supported  by  the  system.  Mandatory  security  refers  to 
the  enforcement  of  a  set  of  access  control  rules  that  constrains  a 
subject's  access  to  information  on  the  basis  of  a  comparison  of  that 
individual's  clearance/authorization  to  the  information,  the  classification/ 
sensitivity  designation  of  the  information,  and  the  form  of  access  being 
mediated.  Mandatory  policies  either  require  or  can  be  satisfied  by 
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systems  that  can  enforce  a  partial  ordering  of  designations,  namely,  the 
designations  must  form  what  is  mathematically  known  as  a  lattice.[5] 

A  clear  implication  of  the  above  is  that  the  system  must  assure  that  the 
designations  associated  with  sensitive  data  cannot  be  arbitrarily  changed, 
since  this  could  permit  individuals  who  lack  the  appropriate  authoriza¬ 
tion  to  access  sensitive  information.  Also  implied  is  the  requirement  that 
the  system  control  the  flow  of  information  so  that  data  cannot  be  stored 
with  lower  sensitivity  designations  unless  its  "downgrading"  has  been 
authorized.  The  control  objective  is: 


MANDATORY  SECURITY  CONTROL  OBJECTIVE 

Security  policies  defined  for  systems  that  are  used  to  process 
classified  or  other  specifically  categorized  sensitive  information 
must  include  provisions  for  the  enforcement  of  mandatory  access 
control  rules.  That  is,  they  must  include  a  set  of  rules  for 
controlling  access  based  directly  on  a  comparison  of  the 
individual's  clearance  or  authorization  for  the  information  and 
the  classification  or  sensitivity  designation  of  the  information 
being  sought,  and  indirectly  on  considerations  of  physical  and 
other  environmental  factors  of  control.  The  mandatory  access 
control  rules  must  accurately  reflect  the  laws,  regulations,  and 
general  policies  from  which  they  are  derived. 


5.3. 1 .2  Discretionary  Security  Policy 

Discretionary  security  is  the  principal  type  of  access  control  available  in 
computer  systems  today.  The  basis  of  this  kind  of  security  is  that  an 
individual  user,  or  program  operating  on  his  behalf,  is  allowed  to  specify 
explicitly  the  types  of  access  other  users  may  have  to  information  under 
his  control.  Discretionary  security  differs  from  mandatory  security  in 
that  it  implements  an  access  control  policy  on  the  basis  of  an 
individual's  need-to-know  as  opposed  to  mandatory  controls  which  are 
driven  by  the  classification  or  sensitivity  designation  of  the  information. 

Discretionary  controls  are  not  a  replacement  for  mandatory  controls.  In 
an  environment  in  which  information  is  classified  (as  in  the  DoD) 
discretionary  security  provides  for  a  finer  granularity  of  control  within 
the  overall  constraints  of  the  mandatory  policy.  Access  to  classified 
information  requires  effective  implementation  of  both  types  of  controls 
as  precondition  to  granting  that  access.  In  general,  no  person  may  have 
access  to  classified  information  unless:  (a)  that  person  has  been 
determined  to  be  trustworthy,  i.e.,  granted  a  personnel  security  clearance 
--  MANDATORY,  and  (b)  access  is  necessary  for  the  performance  of 
official  duties,  i.e.,  determined  to  have  a  need-to-know  --  DISCRE¬ 
TIONARY.  In  other  words,  discretionary  controls  give  individuals 
discretion  to  decide  on  which  of  the  permissible  accesses  will  actually  be 
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allowed  to  which  users,  consistent  with  overriding  mandatory  policy 
restrictions.  The  control  objective  is: 


DISCRETIONARY  SECURITY  CONTROL  OBJECTIVE 

Security  policies  defined  for  systems  that  are  used  to  process 
classified  or  other  sensitive  information  must  include  provisions 
for  the  enforcement  of  discretionary  access  control  rules.  That 
is,  they  must  include  a  consistent  set  of  rules  for  controlling  and 
limiting  access  based  on  identified  individuals  who  have  been 
determined  to  have  a  need-to-know  for  the  information. 


5. 3. 1.3  Marking 

To  implement  a  set  of  mechanisms  that  will  put  into  effect  a  mandatory 
security  policy,  it  is  necessary  that  the  system  mark  information  with 
appropriate  classification  or  sensitivity  labels  and  maintain  these 
markings  as  the  information  moves  through  the  system.  Once 
information  is  unalterably  and  accurately  marked,  comparisons  required 
by  the  mandatory  access  control  rules  can  be  accurately  and  consistently 
made.  An  additional  benefit  of  having  the  system  maintain  the 
classification  or  sensitivity  label  internally  is  the  ability  to  automatically 
generate  properly  "labeled"  output.  The  labels,  if  accurately  and 
integrally  maintained  by  the  system,  remain  accurate  when  output  from 
the  system.  The  control  objective  is: 


MARKING  CONTROL  OBJECTIVE 

Systems  that  are  designed  to  enforce  a  mandatory  security 
policy  must  store  and  preserve  the  integrity  of  classification  or 
other  sensitivity  labels  for  all  information.  Labels  exported 
from  the  system  must  be  accurate  representations  of  the 
corresponding  internal  sensitivity  labels  being  exported. 


5.3.2  Accountability 

The  second  basic  control  objective  addresses  one  of  the  fundamental  principles 
of  security,  i.e. ,  individual  accountability.  Individual  accountability  is  the  key 
to  securing  and  controlling  any  system  that  processes  information  on  behalf  of 
individuals  or  groups  of  individuals.  A  number  of  requirements  must  be  met  in 
order  to  satisfy  this  objective. 

The  first  requirement  is  for  individual  user  identification.  Second,  there  is  a 
need  for  authentication  of  the  identification.  Identification  is  functionally 
dependent  on  authentication.  Without  authentication,  user  identification  has 
no  credibility.  Without  a  credible  identity,  neither  mandatory  nor  discretionary 
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security  policies  can  be  properly  invoked  because  there  is  no  assurance  that 
proper  authorizations  can  be  made. 

The  third  requirement  is  for  dependable  audit  capabilities.  That  is,  a  trusted 
computer  system  must  provide  authorized  personnel  with  the  ability  to  audit 
any  action  that  can  potentially  cause  access  to,  generation  of,  or  effect  the 
release  of  classified  or  sensitive  information.  The  audit  data  will  be  selectively 
acquired  based  on  the  auditing  needs  of  a  particular  installation  and/or 
application.  However,  there  must  be  sufficient  granularity  in  the  audit  data  to 
support  tracing  the  auditable  events  to  a  specific  individual  who  has  taken  the 
actions  or  on  whose  behalf  the  actions  were  taken.  The  control  objective  is: 


ACCOUNTABILITY  CONTROL  OBJECTIVE 

Systems  that  are  used  to  process  or  handle  classified  or  other 
sensitive  information  must  assure  individual  accountability  whenever 
either  a  mandatory  or  discretionary  security  policy  is  invoked. 
Furthermore,  to  assure  accountability  the  capability  must  exist  for  an 
authorized  and  competent  agent  to  access  and  evaluate  accountability 
information  by  a  secure  means,  within  a  reasonable  amount  of  time, 
and  without  undue  difficulty. 


5.3.3  Assurance 

The  third  basic  control  objective  is  concerned  with  guaranteeing  or  providing 
confidence  that  the  security  policy  has  been  implemented  correctly  and  that  the 
protection-relevant  elements  of  the  system  do,  indeed,  accurately  mediate  and 
enforce  the  intent  of  that  policy.  By  extension,  assurance  must  include  a 
guarantee  that  the  trusted  portion  of  the  system  works  only  as  intended.  To 
accomplish  these  objectives,  two  types  of  assurance  are  needed.  They  are  life- 
cycle  assurance  and  operational  assurance. 

Life-cycle  assurance  refers  to  steps  taken  by  an  organization  to  ensure  that  the 
system  is  designed,  developed,  and  maintained  using  formalized  and  rigorous 
controls  and  standards.[l7]  Computer  systems  that  process  and  store  sensitive 
or  classified  information  depend  on  the  hardware  and  software  to  protect  that 
information.  It  follows  that  the  hardware  and  software  themselves  must  be 
protected  against  unauthorized  changes  that  could  cause  protection  mechanisms 
to  malfunction  or  be  bypassed  completely.  For  this  reason  trusted  computer 
systems  must  be  carefully  evaluated  and  tested  during  the  design  and 
development  phases  and  reevaluated  whenever  changes  are  made  that  could 
affect  the  integrity  of  the  protection  mechanisms.  Only  in  this  way  can 
confidence  be  provided  that  the  hardware  and  software  interpretation  of  the 
security  policy  is  maintained  accurately  and  without  distortion. 

While  life-cycle  assurance  is  concerned  with  procedures  for  managing  system 
design,  development,  and  maintenance;  operational  assurance  focuses  on 
features  and  system  architecture  used  to  ensure  that  the  security  policy  is 
uncircumventably  enforced  during  system  operation.  That  is,  the  security 
policy  must  be  integrated  into  the  hardware  and  software  protection  features  of 
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the  system.  Examples  of  steps  taken  to  provide  this  kind  of  confidence 
include:  methods  for  testing  the  operational  hardware  and  software  for  correct 
operation,  isolation  of  protection-critical  code,  and  the  use  of  hardware  and 
software  to  provide  distinct  domains.  The  control  objective  is: 


ASSURANCE  CONTROL  OBJECTIVE 

Systems  that  are  used  to  process  or  handle  classified  or  other 
sensitive  information  must  be  designed  to  guarantee  correct  and 
accurate  interpretation  of  the  security  policy  and  must  not  distort  the 
intent  of  that  policy.  Assurance  must  be  provided  that  correct 
implementation  and  operation  of  the  policy  exists  throughout  the 
system's  life-cycle. 


/ 
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6.0  RATIONALE  BEHIND  THE 
EVALUATION  CLASSES 
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6.1  The  Reference  Monitor  Concept 

In  October  of  1972,  the  Computer  Security  Technology  Planning  Study,  conducted  by 
James  P.  Anderson  &  Co.,  produced  a  report  for  the  Electronic  Systems  Division 
(ESD)  of  the  United  States  Air  Force.[l]  In  that  report,  the  concept  of  "a  reference 
monitor  which  enforces  the  authorized  access  relationships  between  subjects  and 
objects  of  a  system"  was  introduced.  The  reference  monitor  concept  was  found  to  be 
an  essential  element  of  any  system  that  would  provide  multilevel  secure  computing 
facilities  and  controls. 

The  Anderson  report  went  on  to  define  the  reference  validation  mechanism  as  "an 
implementation  of  the  reference  monitor  concept  .  .  .  that  validates  each  reference  to 
data  or  programs  by  any  user  (program)  against  a  list  of  authorized  types  of  reference 
for  that  user."  It  then  listed  the  three  design  requirements  that  must  be  met  by  a 
reference  validation  mechanism: 

a.  The  reference  validation  mechanism  must  be  tamper  proof. 

b.  The  reference  validation  mechanism  must  always  be  invoked. 

c.  The  reference  validation  mechanism  must  be  small  enough  to  be  subject 
to  analysis  and  tests,  the  completeness  of  which  can  be  assured.!  1] 

Extensive  peer  review  and  continuing  research  and  development  activities  have 
sustained  the  validity  of  the  Anderson  Committee's  findings.  Early  examples  of  the 
reference  validation  mechanism  were  known  as  security  kernels.  The  Anderson  Report 
described  the  security  kernel  as  "that  combination  of  hardware  and  software  which 
implements  the  reference  monitor  concept. "[1]  In  this  vein,  it  will  be  noted  that  the 
security  kernel  must  support  the  three  reference  monitor  requirements  listed  above. 


6.2  A  Formal  Security  Policy  Model 

Following  the  publication  of  the  Anderson  report,  considerable  research  was  initiated 
into  formal  models  of  security  policy  requirements  and  of  the  mechanisms  that  would 
implement  and  enforce  those  policy  models  as  a  security  kernel.  Prominent  among 
these  efforts  was  the  ESD-sponsored  development  of  the  Bell  and  LaPadula  model,  an 
abstract  formal  treatment  of  DoD  security  policy. [2]  Using  mathematics  and  set 
theory,  the  model  precisely  defines  the  notion  of  secure  state,  fundamental  modes  of 
access,  and  the  rules  for  granting  subjects  specific  modes  of  access  to  objects. 
Finally,  a  theorem  is  proven  to  demonstrate  that  the  rules  are  security-preserving 
operations,  so  that  the  application  of  any  sequence  of  the  rules  to  a  system  that  is  in 
a  secure  state  will  result  in  the  system  entering  a  new  state  that  is  also  secure.  This 
theorem  is  known  as  the  Basic  Security  Theorem. 

The  Bell  and  LaPadula  model  defines  a  relationship  between  clearances  of  subjects 
and  classifications  of  system  objects,  now  referenced  as  the  dominance  relation.  From 
this  definition,  accesses  permitted  between  subjects  and  objects  are  explicitly  defined 
for  the  fundamental  modes  of  access,  including  read-only  access,  read/write  access, 
and  write-only  access.  The  model  defines  the  Simple  Security  Condition  to  control 
granting  a  subject  read  access  to  a  specific  object,  and  the  "-Property  (read  "Star 
Property")  to  control  granting  a  subject  write  access  to  a  specific  object.  Both  the 
Simple  Security  Condition  and  the  "-Property  include  mandatory  security  provisions 
based  on  the  dominance  relation  between  the  clearance  of  the  subject  and  the 
classification  of  the  object.  The  Discretionary  Security  Property  is  also  defined,  and 
requires  that  a  specific  subject  be  authorized  for  the  particular  mode  of  access 
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required  for  the  state  transition.  In  its  treatment  of  subjects  (processes  acting  on 
behalf  of  a  user),  the  model  distinguishes  between  trusted  subjects  (i.e.,  not 
constrained  within  the  model  by  the  "-Property)  and  untrusted  subjects  (those  that  are 
constrained  by  the  "-Property). 

From  the  Bell  and  LaPadula  model  there  evolved  a  model  of  the  method  of  proof 
required  to  formally  demonstrate  that  all  arbitrary  sequences  of  state  transitions  are 
security-preserving.  It  was  also  shown  that  the  "-Property  is  sufficient  to  prevent  the 
compromise  of  information  by  Trojan  Horse  attacks. 


6.3  The  Trusted  Computing  Base 

In  order  to  encourage  the  widespread  commercial  availability  of  trusted  computer 
systems,  these  evaluation  criteria  have  been  designed  to  address  those  systems  in 
which  a  security  kernel  is  specifically  implemented  as  well  as  those  in  which  a  security 
kernel  has  not  been  implemented.  The  latter  case  includes  those  systems  in  which 
objective  (c)  is  not  fully  supported  because  of  the  size  or  complexity  of  the  reference 
validation  mechanism.  For  convenience,  these  evaluation  criteria  use  the  term  Trusted 
Computing  Base  to  refer  to  the  reference  validation  mechanism,  be  it  a  security  kernel, 
front-end  security  filter,  or  the  entire  trusted  computer  system. 

The  heart  of  a  trusted  computer  system  is  the  Trusted  Computing  Base  (TCB)  which 
contains  all  of  the  elements  of  the  system  responsible  for  supporting  the  security 
policy  and  supporting  the  isolation  of  objects  (code  and  data)  on  which  the  protection 
is  based.  The  bounds  of  the  TCB  equate  to  the  "security  perimeter"  referenced  in 
some  computer  security  literature.  In  the  interest  of  understandable  and  maintainable 
protection,  a  TCB  should  be  as  simple  as  possible  consistent  with  the  functions  it  has 
to  perform.  Thus,  the  TCB  includes  hardware,  firmware,  and  software  critical  to 
protection  and  must  be  designed  and  implemented  such  that  system  elements  excluded 
from  it  need  not  be  trusted  to  maintain  protection.  Identification  of  the  interface  and 
elements  of  the  TCB  along  with  their  correct  functionality  therefore  forms  the  basis 
for  evaluation. 

For  general-purpose  systems,  the  TCB  will  include  key  elements  of  the  operating 
system  and  may  include  all  of  the  operating  system.  For  embedded  systems,  the 
security  policy  may  deal  with  objects  in  a  way  that  is  meaningful  at  the  application 
level  rather  than  at  the  operating  system  level.  Thus,  the  protection  policy  may  be 
enforced  in  the  application  software  rather  than  in  the  underlying  operating  system. 
The  TCB  will  necessarily  include  all  those  portions  of  the  operating  system  and 
application  software  essential  to  the  support  of  the  policy.  Note  that,  as  the  amount 
of  code  in  the  TCB  increases,  it  becomes  harder  to  be  confident  that  the  TCB 
enforces  the  reference  monitor  requirements  under  all  circumstances. 


6.4  Assurance 

The  third  reference  monitor  design  objective  is  currently  interpreted  as  meaning  that 
the  TCB  must  be  of  sufficiently  simple  organization  and  complexity  to  be  subjected  to 
analysis  and  tests,  the  completeness  of  which  can  be  assured. 

Clearly,  as  the  perceived  degree  of  risk  increases  (e.g.,  the  range  of  sensitivity  of  the 
system's  protected  data,  along  with  the  range  of  clearances  held  by  the  system's  user 
population)  for  a  particular  system's  operational  application  and  environment,  so  also 
must  the  assurances  be  increased  to  substantiate  the  degree  of  trust  that  will  be  placed 
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in  the  system.  The  hierarchy  of  requirements  that  are  presented  for  the  evaluation 
classes  in  the  trusted  computer  system  evaluation  criteria  reflect  the  need  for  these 
assurances. 

As  discussed  in  Section  5.3,  the  evaluation  criteria  uniformly  require  a  statement  of 
the  security  policy  that  is  enforced  by  each  trusted  computer  system.  In  addition,  it 
is  required  that  a  convincing  argument  be  presented  that  explains  why  the  TCB 
satisfies  the  first  two  design  requirements  for  a  reference  monitor.  It  is  not  expected 
that  this  argument  will  be  entirely  formal.  This  argument  is  required  for  each 
candidate  system  in  order  to  satisfy  the  assurance  control  objective. 

The  systems  to  which  security  enforcement  mechanisms  have  been  added,  rather  than 
built-in  as  fundamental  design  objectives,  are  not  readily  amenable  to  extensive 
analysis  since  they  lack  the  requisite  conceptual  simplicity  of  a  security  kernel.  This 
is  because  their  TCB  extends  to  cover  much  of  the  entire  system.  Hence,  their 
degree  of  trustworthiness  can  best  be  ascertained  only  by  obtaining  test  results.  Since 
no  test  procedure  for  something  as  complex  as  a  computer  system  can  be  truly 
exhaustive,  there  is  always  the  possibility  that  a  subsequent  penetration  attempt  could 
succeed.  It  is  for  this  reason  that  such  systems  must  fall  into  the  lower  evaluation 
classes. 

On  the  other  hand,  those  systems  that  are  designed  and  engineered  to  support  the 
TCB  concepts  are  more  amenable  to  analysis  and  structured  testing.  Formal  methods 
can  be  used  to  analyze  the  correctness  of  their  reference  validation  mechanisms  in 
enforcing  the  system's  security  policy.  Other  methods,  including  less-formal 
arguments,  can  be  used  in  order  to  substantiate  claims  for  the  completeness  of  their 
access  mediation  and  their  degree  of  tamper-resistance.  More  confidence  can  be 
placed  in  the  results  of  this  analysis  and  in  the  thoroughness  of  the  structured  testing 
than  can  be  placed  in  the  results  for  less  methodically  structured  systems.  For  these 
reasons,  it  appears  reasonable  to  conclude  that  these  systems  could  be  used  in  higher- 
risk  environments.  Successful  implementations  of  such  systems  would  be  placed  in 
the  higher  evaluation  classes. 


6.5  The  Classes 

It  is  highly  desirable  that  there  be  only  a  small  number  of  overall  evaluation  classes. 
Three  major  divisions  have  been  identified  in  the  evaluation  criteria  with  a  fourth 
division  reserved  for  those  systems  that  have  been  evaluated  and  found  to  offer 
unacceptable  security  protection.  Within  each  major  evaluation  division,  it  was 
found  that  "intermediate"  classes  of  trusted  system  design  and  development  could 
meaningfully  be  defined.  These  intermediate  classes  have  been  designated  in  the 
criteria  because  they  identify  systems  that: 

are  viewed  to  offer  significantly  better  protection  and  assurance  than  would 
systems  that  satisfy  the  basic  requirements  for  their  evaluation  class;  and 

there  is  reason  to  believe  that  systems  in  the  intermediate  evaluation  classes 
could  eventually  be  evolved  such  that  they  would  satisfy  the  requirements 
for  the  next  higher  evaluation  class. 

Except  within  division  A  it  is  not  anticipated  that  additional  "intermediate"  evaluation 
classes  satisfying  the  two  characteristics  described  above  will  be  identified. 

Distinctions  in  terms  of  system  architecture,  security  policy  enforcement,  and 
evidence  of  credibility  between  evaluation  classes  have  been  defined  such  that  the 
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"jump"  between  evaluation  classes  would  require  a  considerable  investment  of  effort 
on  the  part  of  implementors.  Correspondingly,  there  are  expected  to  be  significant 
differentials  of  risk  to  which  systems  from  the  higher  evaluation  classes  will  be 


exposed. 
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7.0  THE  RELATIONSHIP  BETWEEN  POLICY  AND 

THE  CRITERIA 


Section  I  presents  fundamental  computer  security  requirements  and  Section  5  presents  the 
control  objectives  for  Trusted  Computer  Systems.  They  are  general  requirements,  useful 
and  necessary,  for  the  development  of  all  secure  systems.  However,  when  designing 
systems  that  will  be  used  to  process  classified  or  other  sensitive  information,  functional 
requirements  for  meeting  the  Control  Objectives  become  more  specific.  There  is  a  large 
body  of  policy  laid  down  in  the  form  of  Regulations,  Directives,  Presidential  Executive 
Orders,  and  OMB  Circulars  that  form  the  basis  of  the  procedures  for  the  handling  and 
processing  of  Federal  information  in  general  and  classified  information  specifically.  This 
section  presents  pertinent  excerpts  from  these  policy  statements  and  discusses  their 
relationship  to  the  Control  Objectives. 
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7.1  Established  Federal  Policies 

A  significant  number  of  computer  security  policies  and  associated  requirements  have 
been  promulgated  by  Federal  government  elements.  The  interested  reader  is  referred 
to  reference  [32]  which  analyzes  the  need  for  trusted  systems  in  the  civilian  agencies 
of  the  Federal  government,  as  well  as  in  state  and  local  governments  and  in  the 
private  sector.  This  reference  also  details  a  number  of  relevant  Federal  statutes, 
policies  and  requirements  not  treated  further  below. 

Security  guidance  for  Federal  automated  information  systems  is  provided  by  the 
Office  of  Management  and  Budget.  Two  specifically  applicable  Circulars  have  been 
issued.  OMB  Circular  No.  A-71,  Transmittal  Memorandum  No.  I,  Security  of 
Federal  Automated  Information  Systems,[ 26]  directs  each  executive  agency  to  establish 
and  maintain  a  computer  security  program.  It  makes  the  head  of  each  executive 
branch  department  and  agency  responsible  "for  assuring  an  adequate  level  of  security 
for  all  agency  data  whether  processed  in-house  or  commercially.  This  includes 
responsibility  for  the  establishment  of  physical,  administrative  and  technical 
safeguards  required  to  adequately  protect  personal,  proprietary  or  other  sensitive  data 
not  subject  to  national  security  regulations,  as  well  as  national  security  data. "[26, 
para.  4] 

OMB  Circular  No.  A- 1 23,  Internal  Control  Systems,[2T]  issued  to  help  eliminate 
fraud,  waste,  and  abuse  in  government  programs  requires:  (a)  agency  heads  to  issue 
internal  control  directives  and  assign  responsibility,  (b)  managers  to  review  programs 
for  vulnerability,  and  (c)  managers  to  perform  periodic  reviews  to  evaluate  strengths 
and  update  controls.  Soon  after  promulgation  of  OMB  Circular  A- 123,  the 
relationship  of  its  internal  control  requirements  to  building  secure  computer  systems 
was  recognized. [4]  While  not  stipulating  computer  controls  specifically,  the 
definition  of  Internal  Controls  in  A- 1 23  makes  it  clear  that  computer  systems  are  to 
be  included: 

Internal  Controls  --  the  plan  of  organization  and  all  of  the  methods  and 
measures  adopted  within  an  agency  to  safeguard  its  resources,  assure  the 
accuracy  and  reliability  of  its  information,  assure  adherence  to  applicable  laws, 
regulations  and  policies,  and  promote  operational  economy  and  efficiency. [27, 
sec.  4.c] 

The  matter  of  classified  national  security  information  processed  by  ADP  systems  was 
one  of  the  first  areas  given  serious  and  extensive  concern  in  computer  security.  The 
computer  security  policy  documents  promulgated  as  a  result  contain  generally  more 
specific  and  structured  requirements  than  most,  keyed  in  turn  to  an  authoritative 
basis  that  itself  provides  a  rather  clearly  articulated  and  structured  information 
security  policy.  This  basis,  Executive  Order  12356,  National  Security  Information , 
sets  forth  requirements  for  the  classification,  declassification  and  safeguarding  of 
"national  security  information"  per  se.[!4] 


7.2  DoD  Policies 

Within  the  Department  of  Defense,  these  broad  requirements  are  implemented  and 
further  specified  primarily  through  two  vehicles:  I)  DoD  Regulation  5200. 1-R  [7], 
which  applies  to  all  components  of  the  DoD  as  such,  and  2)  DoD  5220. 22-M, 
Industrial  Security  Manual  for  Safeguarding  Classified  Information  [11],  which  applies 
to  contractors  included  within  the  Defense  Industrial  Security  Program.  Note  that 
the  latter  transcends  DoD  as  such,  since  it  applies  not  only  to  any  contractors 
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handling  classified  information  for  any  DoD  component,  but  also  to  the  contractors 
of  eighteen  other  Federal  organizations  for  whom  the  Secretary  of  Defense  is 
authorized  to  act  in  rendering  industrial  security  services.1 

For  ADP  systems,  these  information  security  requirements  are  further  amplified  and 
specified  in:  I)  DoD  Directive  5200.28  [8]  and  DoD  Manual  5200. 28-M  [9],  for 
DoD  components;  and  2)  Section  XIII  of  DoD  5220. 22-M  [II]  for  contractors. 
DoD  Directive  5200.28,  Security  Requirements  for  Automatic  Data  Processing  (ADP) 
Systems,  stipulates:  "Classified  material  contained  in  an  ADP  system  shall  be 
safeguarded  by  the  continuous  employment  of  protective  features  in  the  system's 
hardware  and  software  design  and  configuration  .  .  .  ."[8,  sec.  IV]  Furthermore,  it  is 
required  that  ADP  systems  that  "process,  store,  or  use  classified  data  and  produce 
classified  information  will,  with  reasonable  dependability,  prevent: 

a.  Deliberate  or  inadvertent  access  to  classified  material  by  unauthorized 
persons,  and 

b.  Unauthorized  manipulation  of  the  computer  and  its  associated  peripheral 
devices. "[8,  sec.  I  B.3] 

Requirements  equivalent  to  these  appear  within  DoD  5200. 28-M  [9]  and  in  DoD 
5220. 22-M  [II]. 

From  requirements  imposed  by  these  regulations,  directives  and  circulars,  the  three 
components  of  the  Security  Policy  Control  Objective,  i.e.,  Mandatory  and 
Discretionary  Security  and  Marking,  as  well  as  the  Accountability  and  Assurance 
Control  Objectives,  can  be  functionally  defined  for  DoD  applications.  The  following 
discussion  provides  further  specificity  in  Policy  for  these  Control  Objectives. 


7.3  Criteria  Control  Objective  for  Security  Policy 
7.3.1  Marking 

The  control  objective  for  marking  is:  Systems  that  are  designed  to  enforce  a 
mandatory  security  policy  must  store  and  preserve  the  integrity  of  classification  or 
other  sensitivity  labels  for  all  information .  Labels  exported  from  the  system  must 
be  accurate  representations  of  the  corresonding  internal  sensitivity  labels  being 
exported. 

DoD  5220. 22-M,  Industrial  Security  Manual  for  Safeguarding  Classified 
Information ,  explains  in  paragraph  1 1  the  reasons  for  marking  information: 

Designation  by  physical  marking,  notation  or  other  means  serves  to 
inform  and  to  warn  the  holder  of  the  classification  designation  of  the 
information  which  requires  protection  in  the  interest  of  national 
security.  The  degree  of  protection  against  unauthorized  disclosure 
which  will  be  required  for  a  particular  level  of  classification  is  directly 
commensurate  with  the  marking  designation  which  is  assigned  to  the 
material.!  1 1] 


1  i.e.,  NASA,  Commerce  Department,  GSA,  State  Department,  Small  Business  Administration,  National 
Science  Foundation,  Treasury  Department,  Transportation  Department,  Interior  Department,  Agriculture 
Department,  Health  and  Human  Services  Department,  Labor  Department,  Environmental  Protection 
Agency,  Justice  Department,  U.S.  Arms  Control  and  Disarmament  Agency,  Federal  Emergency 
Management  Agency,  Federal  Reserve  System,  and  U.S.  General  Accounting  Office. 
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Marking  requirements  are  given  in  a  number  of  policy  statements. 

Executive  Order  12356  (Sections  l.5.a  and  I.S.a.l)  requires  that  classification 
markings  "shall  be  shown  on  the  face  of  all  classified  documents,  or  clearly 
associated  with  other  forms  of  classified  information  in  a  manner  appropriate 
to  the  medium  involved. "[1 4] 

DoD  Regulation  5200. 1-R  (Paragraph  1-500)  requires  that:  "Information  or 
material  that  requires  protection  against  unauthorized  disclosure  in  the  interest 
of  national  security  shall  be  classified  in  one  of  three  designations,  namely: 
'Top  Secret,'  'Secret,'  or  ' Confidential. ’  "[7]  (By  extension,  for  use  in 
computer  processing,  the  unofficial  designation  "Unclassified"  is  used  to 
indicate  information  that  does  not  fall  under  one  of  the  other  three 
designations  of  classified  information.) 

DoD  Regulation  5200. 1-R  (Paragraph  4-304b)  requires  that:  "ADP  systems 
and  word  processing  systems  employing  such  media  shall  provide  for  internal 
classification  marking  to  assure  that  classified  information  contained  therein 
that  is  reproduced  or  generated,  will  bear  applicable  classification  and 
associated  markings."  (This  regulation  provides  for  the  exemption  of  certain 
existing  systems  where  "internal  classification  and  applicable  associated 
markings  cannot  be  implemented  without  extensive  system  modification. "[7] 
However,  it  is  clear  that  future  DoD  ADP  systems  must  be  able  to  provide 
applicable  and  accurate  labels  for  classified  and  other  sensitive  information.) 

DoD  Manual  5200. 28-M  (Paragraph  4-305d)  requires  the  following:  "Security 
Labels  -  All  classified  material  accessible  by  or  within  the  ADP  System  shall  be 
identified  as  to  its  security  classification  and  access  or  dissemination  limitations, 
and  all  output  of  the  ADP  system  shall  be  appropriately  marked. "[9] 

7.3.2  Mandatory  Security 

The  control  objective  for  mandatory  security  is:  Security  policies  defined  for 
systems  that  are  used  to  process  classified  or  other  specifically  categorized  sensitive 
information  must  include  provisions  for  the  enforcement  of  mandatory  access 
control  rules.  That  is,  they  must  include  a  set  of  rules  for  controlling  access  based 
directly  on  a  comparison  of  the  individual' s  clearance  or  authorization  for  the 
information  and  the  classification  or  sensitivity  designation  of  the  information 
being  sought,  and  indirectly  on  considerations  of  physical  and  other  environmental 
factors  of  control.  The  mandatory  access  control  rules  must  accurately  reflect  the 
laws,  regulations,  and  general  policies  from  which  they  are  derived. 

There  are  a  number  of  policy  statements  that  are  related  to  mandatory  security. 

Executive  Order  12356  (Section  4.1. a)  states  that  "a  person  is  eligible  for 
access  to  classified  information  provided  that  a  determination  of  trustworthi¬ 
ness  has  been  made  by  agency  heads  or  designated  officials  and  provided  that 
such  access  is  essential  to  the  accomplishment  of  lawful  and  authorized 
Government  purposes. "[1 4] 

DoD  Regulation  5200. 1-R  (Paragraph  1-328)  defines  a  Special  Access  Program 
as  "any  program  imposing  '  need-to-know'  or  access  controls  beyond  those 
normally  provided  for  access  to  Confidential,  Secret,  or  Top  Secret 
information.  Such  a  program  includes,  but  is  not  limited  to,  special  clearance, 
adjudication,  or  investigative  requirements,  special  designation  of  officials 
authorized  to  determine  'need-to-know',  or  special  lists  of  persons  determined 
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to  have  a  '  need-to-know. '  "[7]  This  passage  distinguishes  between  a 
"discretionary"  determination  of  need-to-know  and  formal  need-to-know  which 
is  implemented  through  Special  Access  Programs.  DoD  Regulation  5200. 1-R, 
paragraph  7-100  describes  general  requirements  for  trustworthiness  (clearance) 
and  need-to-know,  and  states  that  the  individual  with  possession,  knowledge  or 
control  of  classified  information  has  final  responsibility  for  determining  if 
conditions  for  access  have  been  met.  This  regulation  further  stipulates  that  "no 
one  has  a  right  to  have  access  to  classified  information  solely  by  virtue  of  rank 
or  position. "[7,  para.  7-100] 

DoD  Manual  5200. 28-M  (Paragraph  2-100)  states  that,  "Personnel  who 
develop,  test(debug),  maintain,  or  use  programs  which  are  classified  or  which 
will  be  used  to  access  or  develop  classified  material  shall  have  a  personnel 
security  clearance  and  an  access  authorization  (need-to-know),  as  appropriate 
for  the  highest  classified  and  most  restrictive  category  of  classified  material 
which  they  will  access  under  system  constraints. "[9] 

DoD  Manual  5220. 22-M  (Paragraph  3a)  defines  access  as  "the  ability  and 
opportunity  to  obtain  knowledge  of  classified  information.  An  individual,  in 
fact,  may  have  access  to  classified  information  by  being  in  a  place  where  such 
information  is  kept,  if  the  security  measures  which  are  in  force  do  not  prevent 
him  from  gaining  knowledge  of  the  classified  information."!  1 1] 

The  above  mentioned  Executive  Order,  Regulation,  and  Manuals  clearly  imply 
that  a  trusted  computer  system  must  assure  that  the  classification  labels 
associated  with  sensitive  data  cannot  be  arbitrarily  changed,  since  this  could 
permit  individuals  who  lack  the  appropriate  clearance  to  access  classified 
information.  Also  implied  is  the  requirement  that  a  trusted  computer  system 
must  control  the  flow  of  information  so  that  data  from  a  higher  classification 
cannot  be  placed  in  a  storage  object  of  lower  classification  unless  its 
"downgrading"  has  been  authorized. 

7.3.3  Discretionary  Security 

The  term  discretionary  security  refers  to  a  computer  system's  ability  to  control 
information  on  an  individual  basis.  It  stems  from  the  fact  that  even  though  an 
individual  has  all  the  formal  clearances  for  access  to  specific  classified 
information,  each  individual's  access  to  information  must  be  based  on  a 
demonstrated  need-to-know.  Because  of  this,  it  must  be  made  clear  that  this 
requirement  is  not  discretionary  in  a  "take  it  or  leave  it"  sense.  The  directives 
and  regulations  are  explicit  in  stating  that  the  need-to-know  test  must  be 
satisfied  before  access  can  be  granted  to  the  classified  information.  The  control 
objective  for  discretionary  security  is:  Security  policies  defined  for  systems  that 
are  used  to  process  classified  or  other  sensitive  information  must  include  provisions 
for  the  enforcement  of  discretionary  access  control  rules.  That  is,  they  must 
include  a  consistent  set  of  rules  for  controlling  and  limiting  access  based  on 
identified  individuals  who  have  been  determined  to  have  a  need-to-know  for  the 
information. 

DoD  Regulation  5200. 1-R  (Paragraph  7-100)  In  addition  to  excerpts  already 
provided  that  touch  on  need-to-know,  this  section  of  the  regulation  stresses  the 
need-to-know  principle  when  it  states  "no  person  may  have  access  to  classified 
information  unless  .  .  .  access  is  necessary  for  the  performance  of  official 
duties.  "[7] 
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Also  DoD  Manual  5220. 22-M  (Paragraph  20a)  states  that  "an  individual  shall 
be  permitted  to  have  access  to  classified  information  only  .  .  .  when  the 
contractor  determines  that  access  is  necessary  in  the  performance  of  tasks  or 
services  essential  to  the  fulfillment  of  a  contract  or  program,  i.e.,  the  individual 
has  a  need-to-know."[l  I] 

7.4  Criteria  Control  Objective  for  Accountability 

The  control  objective  for  accountability  is:  Systems  that  are  used  to  process  or  handle 
classified  or  other  sensitive  information  must  assure  individual  accountability  whenever 
either  a  mandatory  or  discretionary  security  policy  is  invoked.  Furthermore,  to  assure 
accountability  the  capability  must  exist  for  an  authorized  and  competent  agent  to  access 
and  evaluate  accountability  information  by  a  secure  means,  within  a  reasonable  amount 
of  time,  and  without  undue  difficulty. 

This  control  objective  is  supported  by  the  following  citations: 

DoD  Directive  5200.28  (Section  VI. A.  1)  states:  "Each  user's  identity  shall  be 
positively  established,  and  his  access  to  the  system,  and  his  activity  on  the  system 
(including  material  accessed  and  actions  taken)  controlled  and  open  to  scrutiny. " [8] 

DoD  Manual  5200. 28-M  (Paragraph  5-100)  states:  "An  audit  log  or  file  (manual, 
machine,  or  a  combination  of  both)  shall  be  maintained  as  a  history  of  the  use  of  the 
ADP  System  to  permit  a  regular  security  review  of  system  activity,  (e.g.,  The  log 
should  record  security  related  transactions,  including  each  access  to  a  classified  file 
and  the  nature  of  each  access,  e.g.,  logins,  production  of  accountable  classified 
outputs,  and  creation  of  new  classified  files.  Each  classified  file  successfully  accessed 
[regardless  of  the  number  of  individual  references]  during  each  'job'  or  'interactive 
session'  should  also  be  recorded  in  the  audit  log.  Much  of  the  material  in  this  log 
may  also  be  required  to  assure  that  the  system  preserves  information  entrusted  to 
it-)"  [9] 

DoD  Manual  5200. 28-M  (Paragraph  4-305f)  states:  "Where  needed  to  assure  control 
of  access  and  individual  accountability,  each  user  or  specific  group  of  users  shall  be 
identified  to  the  ADP  System  by  appropriate  administrative  or  hardware/software 
measures.  Such  identification  measures  must  be  in  sufficient  detail  to  enable  the  ADP 
System  to  provide  the  user  only  that  material  which  he  is  authorized. "[9] 

DoD  Manual  5200. 28-M  (Paragraph  1  - 1 02b)  states: 

Component's  Designated  Approving  Authorities,  or  their  designees  for  the 
purpose  .  .  .  will  assure: 


4.  Maintenance  of  documentation  on  operating  systems  (O/S)  and  all 
modifications  thereto,  and  its  retention  for  a  sufficient  period  of  time  to 
enable  tracing  of  security-related  defects  to  their  point  of  origin  or  inclusion 
in  the  system. 


6.  Establishment  of  procedures  to  discover,  recover,  handle,  and  dispose 
of  classified  material  improperly  disclosed  through  system  malfunction  or 
personnel  action. 
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7.  Proper  disposition  and  correction  of  security  deficiencies  in  all 
approved  ADP  Systems,  and  the  effective  use  and  disposition  of  system 
housekeeping  or  audit  records,  records  of  security  violations  or  security- 
related  system  malfunctions,  and  records  of  tests  of  the  security  features  of  an 
ADP  System. [9] 

DoD  Manual  5220. 22-M  (Paragraph  1 1 1)  on  audit  trails  states: 

a.  The  general  security  requirement  for  any  ADP  system  audit  trail  is  that  it 
provide  a  documented  history  of  the  use  of  the  system.  An  approved  audit 
trail  will  permit  review  of  classified  system  activity  and  will  provide  a  detailed 
activity  record  to  facilitate  reconstruction  of  events  to  determine  the 
magnitude  of  compromise  (if  any)  should  a  security  malfunction  occur.  To 
fulfill  this  basic  requirement,  audit  trail  systems,  manual,  automated  or  a 
combination  of  both  must  document  significant  events  occurring  in  the 
following  areas  of  concern:  (/)  preparation  of  input  data  and  dissemination  of 
output  data  (i.e.,  reportable  interactivity  between  users  and  system  support 
personnel),  (//)  activity  involved  within  an  ADP  environment  (e.g.,  ADP 
support  personnel  modification  of  security  and  related  controls),  and 
(iii)  internal  machine  activity. 

b.  The  audit  trail  for  an  ADP  system  approved  to  process  classified 
information  must  be  based  on  the  above  three  areas  and  may  be  stylized  to  the 
particular  system.  All  systems  approved  for  classified  processing  should 
contain  most  if  not  all  of  the  audit  trail  records  listed  below.  The 
contractor's  SSP  documentation  must  identify  and  describe  those  applicable: 

(1)  Personnel  access; 

(2)  Unauthorized  and  surreptitious  entry  into  the  central  computer  facility 
or  remote  terminal  areas; 

(3)  Start/stop  time  of  classified  processing  indicating  pertinent  systems 
security  initiation  and  termination  events  (e.g.,  upgrading/downgrading  actions 
pursuant  to  paragraph  107); 

(4)  All  functions  initiated  by  ADP  system  console  operators; 

(5)  Disconnects  of  remote  terminals  and  peripheral  devices  (paragraph 
107c); 

(6)  Log-on  and  log-off  user  activity; 

(7)  Unauthorized  attempts  to  access  files  or  programs,  as  well  as  all  open, 
close,  create,  and  file  destroy  actions; 

(8)  Program  aborts  and  anomalies  including  identification  information 
(i.e.,  user/program  name,  time  and  location  of  incident,  etc.); 

(9)  System  hardware  additions,  deletions  and  maintenance  actions; 

(10)  Generations  and  modifications  affecting  the  security  features  of  the 
system  software. 

c.  The  ADP  system  security  supervisor  or  designee  shall  review  the  audit 
trail  logs  at  least  weekly  to  assure  that  all  pertinent  activity  is  properly 
recorded  and  that  appropriate  action  has  been  taken  to  correct  any  anomaly. 
The  majority  of  ADP  systems  in  use  today  can  develop  audit  trail  systems  in 
accord  with  the  above;  however,  special  systems  such  as  weapons, 
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communications,  communications  security,  and  tactical  data  exchange  and 
display  systems,  may  not  be  able  to  comply  with  all  aspects  of  the  above  and 
may  require  individualized  consideration  by  the  cognizant  security  office. 

d.  Audit  trail  records  shall  be  retained  for  a  period  of  one  inspection 
cycle. [1 1] 


7.5  Criteria  Control  Objective  for  Assurance 

The  control  objective  for  assurance  is:  "Systems  that  are  used  to  process  or  handle 
classified  or  other  sensitive  information  must  be  designed  to  guarantee  correct  and 
accurate  interpretation  of  the  security  policy  and  must  not  distort  the  intent  of  that 
policy.  Assurance  must  be  provided  that  correct  implementation  and  operation  of  the 
policy  exists  throughout  the  system's  life-cycle." 

A  basis  for  this  objective  can  be  found  in  the  following  sections  of  DoD  Directive 
5200.28: 

DoD  Directive  5200.28  (Section  IV. B)  stipulates:  "Generally,  security  of  an  ADP 
system  is  most  effective  and  economical  if  the  system  is  designed  originally  to  provide 
it.  Each  Department  of  Defense  Component  undertaking  design  of  an  ADP  system 
which  is  expected  to  process,  store,  use,  or  produce  classified  material  shall: 

I .  From  the  beginning  of  the  design  process,  consider  the  security  policies,  concepts, 
and  measures  prescribed  in  this  Directive. "[8] 

DoD  Directive  5200.28  (Section  IV.C.5.a)  states:  "Provision  may  be  made  to  permit 
adjustment  of  ADP  system  area  controls  to  the  level  of  protection  required  for  the 
classification  category  and  type(s)  of  material  actually  being  handled  by  the  system, 
provided  change  procedures  are  developed  and  implemented  which  will  prevent  both 
the  unauthorized  access  to  classified  material  handled  by  the  system  and  the 
unauthorized  manipulation  of  the  system  and  its  components.  Particular  attention 
shall  be  given  to  the  continuous  protection  of  automated  system  security  measures, 
techniques  and  procedures  when  the  personnel  security  clearance  level  of  users  having 
access  to  the  system  changes. "[8] 

DoD  Directive  5200.28  (Section  VI. A. 2)  states:  "Environmental  Control.  The  ADP 
System  shall  be  externally  protected  to  minimize  the  likelihood  of  unauthorized  access 
to  system  entry  points,  access  to  classified  information  in  the  system,  or  damage  to 
the  system. "[8] 

DoD  Manual  5200. 28-M  (Paragraph  1-1 02b)  states: 

Component's  Designated  Approving  Authorities,  or  their  designees  for  the 
purpose  .  .  .  will  assure: 


5.  Supervision,  monitoring,  and  testing,  as  appropriate,  of  changes  in  an 
approved  ADP  System  which  could  affect  the  security  features  of  the  system, 
so  that  a  secure  system  is  maintained. 


7.  Proper  disposition  and  correction  of  security  deficiencies  in  all 
approved  ADP  Systems,  and  the  effective  use  and  disposition  of  system 
housekeeping  or  audit  records,  records  of  security  violations  or  security- 
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related  system  malfunctions,  and  records  of  tests  of  the  security  features  of  an 
ADP  System. 

8.  Conduct  of  competent  system  ST&E,  timely  review  of  system  ST&E 
reports,  and  correction  of  deficiencies  needed  to  support  conditional  or  final 
approval  or  disapproval  of  an  ADP  System  for  the  processing  of  classified 
information. 

9.  Establishment,  where  appropriate,  of  a  central  ST&E  coordination 
point  for  the  maintenance  of  records  of  selected  techniques,  procedures, 
standards,  and  tests  used  in  the  testing  and  evaluation  of  security  features  of 
ADP  Systems  which  may  be  suitable  for  validation  and  use  by  other 
Department  of  Defense  Components. [9] 

DoD  Manual  5220. 22-M  (Paragraph  103a)  requires  "the  initial  approval,  in  writing, 
of  the  cognizant  security  office  prior  to  processing  any  classified  information  in  an 
ADP  system.  This  section  requires  reapproval  by  the  cognizant  security  office  for 
major  system  modifications  made  subsequent  to  initial  approval.  Reapprovals  will  be 
required  because  of  (i)  major  changes  in  personnel  access  requirements,  fii)  relocation 
or  structural  modification  of  the  central  computer  facility,  (iii)  additions,  deletions  or 
changes  to  main  frame,  storage  or  input/output  devices,  (iv)  system  software  changes 
impacting  security  protection  features,  (v)  any  change  in  clearance,  declassification, 
audit  trail  or  hardware/software  maintenance  procedures,  and  (vi)  other  system 
changes  as  determined  by  the  cognizant  security  office. "[1 1] 

A  major  component  of  assurance,  life-cycle  assurance,  is  concerned  with  testing  ADP 
systems  both  in  the  development  phase  as  well  as  during  operation.  DoD  Directive 
5215.1  (Section  F.2.C.(2))  requires  "evaluations  of  selected  industry  and  government- 
developed  trusted  computer  systems  against  these  criteria. "[10] 
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8.0  A  GUIDELINE  ON  COVERT  CHANNELS 


A  covert  channel  is  any  communication  channel  that  can  be  exploited  by  a  process  to 
transfer  information  in  a  manner  that  violates  the  system's  security  policy.  There  are  two 
types  of  covert  channels:  storage  channels  and  timing  channels.  Covert  storage  channels 
include  all  vehicles  that  would  allow  the  direct  or  indirect  writing  of  a  storage  location  by 
one  process  and  the  direct  or  indirect  reading  of  it  by  another.  Covert  timing  channels 
include  all  vehicles  that  would  allow  one  process  to  signal  information  to  another  process  by 
modulating  its  own  use  of  system  resources  in  such  a  way  that  the  change  in  response  time 
observed  by  the  second  process  would  provide  information. 

From  a  security  perspective,  covert  channels  with  low  bandwidths  represent  a  lower  threat 
than  those  with  high  bandwidths.  However,  for  many  types  of  covert  channels,  techniques 
used  to  reduce  the  bandwidth  below  a  certain  rate  (which  depends  on  the  specific  channel 
mechanism  and  the  system  architecture)  also  have  the  effect  of  degrading  the  performance 
provided  to  legitimate  system  users.  Hence,  a  trade-off  between  system  performance  and 
covert  channel  bandwidth  must  be  made.  Because  of  the  threat  of  compromise  that  would 
be  present  in  any  multilevel  computer  system  containing  classified  or  sensitive  information, 
such  systems  should  not  contain  covert  channels  with  high  bandwidths.  This  guideline  is 
intended  to  provide  system  developers  with  an  idea  of  just  how  high  a  "high"  covert 
channel  bandwidth  is. 

A  covert  channel  bandwidth  that  exceeds  a  rate  of  one  hundred  (100)  bits  per  second  is 
considered  "high"  because  100  bits  per  second  is  the  approximate  rate  at  which  many 
computer  terminals  are  run.  It  does  not  seem  appropriate  to  call  a  computer  system 
"secure"  if  information  can  be  compromised  at  a  rate  equal  to  the  normal  output  rate  of 
some  commonly  used  device. 

In  any  multilevel  computer  system  there  are  a  number  of  relatively  low-bandwidth  covert 
channels  whose  existence  is  deeply  ingrained  in  the  system  design.  Faced  with  the  large 
potential  cost  of  reducing  the  bandwidths  of  such  covert  channels,  it  is  felt  that  those  with 
maximum  bandwidths  of  less  than  one  ( I )  bit  per  second  are  acceptable  in  most  application 
environments.  Though  maintaining  acceptable  performance  in  some  systems  may  make  it 
impractical  to  eliminate  all  covert  channels  with  bandwidths  of  1  or  more  bits  per  second,  it 
is  possible  to  audit  their  use  without  adversely  affecting  system  performance.  This  audit 
capability  provides  the  system  administration  with  a  means  of  detecting  -  and  procedurally 
correcting  --  significant  compromise.  Therefore,  a  Trusted  Computing  Base  should  provide, 
wherever  possible,  the  capability  to  audit  the  use  of  covert  channel  mechanisms  with 
bandwidths  that  may  exceed  a  rate  of  one  (I)  bit  in  ten  (10)  seconds. 

The  covert  channel  problem  has  been  addressed  by  a  number  of  authors.  The  interested 
reader  is  referred  to  references  [5],  [6],  [19],  [21],  [22],  [23],  and  [29]. 
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9.0  A  GUIDELINE  ON  CONFIGURING 
MANDATORY  ACCESS  CONTROL  FEATURES 


The  Mandatory  Access  Control  requirement  includes  a  capability  to  support  an  unspecified 
number  of  hierarchical  classifications  and  an  unspecified  number  of  non-hierarchical 
categories  at  each  hierarchical  level.  To  encourage  consistency  and  portability  in  the  design 
and  development  of  the  National  Security  Establishment  trusted  computer  systems,  it  is 
desirable  for  all  such  systems  to  be  able  to  support  a  minimum  number  of  levels  and 
categories.  The  following  suggestions  are  provided  for  this  purpose: 

*  The  number  of  hierarchical  classifications  should  be  greater  than  or  equal  to  eight 

(8). 

*  The  number  of  non-hierarchical  categories  should  be  greater  than  or  equal  to 
twenty-nine  (29). 
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10.0  A  GUIDELINE  ON  SECURITY  TESTING 


These  guidelines  are  provided  to  give  an  indication  of  the  extent  and  sophistication  of 
testing  undertaken  by  the  DoD  Computer  Security  Center  during  the  Formal  Product 
Evaluation  process.  Organizations  wishing  to  use  "Department  of  Defense  Trusted 
Computer  System  Evaluation  Criteria"  for  performing  their  own  evaluations  may  find  this 
section  useful  for  planning  purposes. 

As  in  Part  I,  highlighting  is  used  to  indicate  changes  in  the  guidelines  from  the  next  lower 
division. 
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10.1  Testing  for  Division  C 

10.1.1  Personnel 

The  security  testing  team  shall  consist  of  at  least  two  individuals  with  bachelor 
degrees  in  Computer  Science  or  the  equivalent.  Team  members  shall  be  able  to 
follow  test  plans  prepared  by  the  system  developer  and  suggest  additions,  shall 
be  familiar  with  the  flaw  hypothesis  or  equivalent  security  testing  methodology, 
and  shall  have  assembly  level  programming  experience.  Before  testing  begins, 
the  team  members  shall  have  functional  knowledge  of,  and  shall  have 
completed  the  system  developer's  internals  course  for,  the  system  being 
evaluated. 

10.1.2  Testing 

The  team  shall  have  "hands-on"  involvement  in  an  independent  run  of  the  tests 
used  by  the  system  developer.  The  team  shall  independently  design  and 
implement  at  least  five  system-specific  tests  in  an  attempt  to  circumvent  the 
security  mechanisms  of  the  system.  The  elapsed  time  devoted  to  testing  shall 
be  at  least  one  month  and  need  not  exceed  three  months.  There  shall  be  no 
fewer  than  twenty  hands-on  hours  spent  carrying  out  system  developer-defined 
tests  and  test  team-defined  tests. 

10.2  Testing  for  Division  B 

10.2.1  Personnel 

The  security  testing  team  shall  consist  of  at  least  two  individuals  with  bachelor 
degrees  in  Computer  Science  or  the  equivalent  and  at  least  one  individual  with 
a  master's  degree  in  Computer  Science  or  equivalent.  Team  members  shall 
be  able  to  follow  test  plans  prepared  by  rhe  system  developer  and  suggest 
additions,  shall  be  conversant  with  the  flaw  hypothesis  or  equivalent  security 
testing  methodology,  shall  be  fluent  in  the  TCB  implementation  language(s), 
and  shall  have  assembly  level  programming  experience.  Before  testing  begins, 
the  team  members  shall  have  functional  knowledge  of,  and  shall  have 
completed  the  system  developer's  internals  course  for,  the  system  being 
evaluated.  At  least  one  team  member  shall  have  previously  completed  a 
security  test  on  another  system. 

10.2.2  Testing 

The  team  shall  have  "hands-on"  involvement  in  an  independent  run  of  the  test 
package  used  by  the  system  developer  to  test  security-relevant  hardware  and 
software.  The  team  shall  independently  design  and  implement  at  least  fifteen 
system-specific  tests  in  an  attempt  to  circumvent  the  security  mechanisms  of 
the  system.  The  elapsed  time  devoted  to  testing  shall  be  at  least  two  months 
and  need  not  exceed  four  months.  There  shall  be  no  fewer  than  thirty  hands- 
on  hours  per  team  member  spent  carrying  out  system  developer-defined  tests 
and  test  team-defined  tests. 
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10.3  Testing  for  Division  A 

10.3.1  Personnel 

The  security  testing  team  shall  consist  of  at  least  one  individual  with  a 
bachelor's  degree  in  Computer  Science  or  the  equivalent  and  at  least  two 
individuals  with  masters'  degrees  in  Computer  Science  or  equivalent.  Team 
members  shall  be  able  to  follow  test  plans  prepared  by  the  system  developer 
and  suggest  additions,  shall  be  conversant  with  the  flaw  hypothesis  or  equivalent 
security  testing  methodology,  shall  be  fluent  in  the  TCB  implementation 
language(s),  and  shall  have  assembly  level  programming  experience.  Before 
testing  begins,  the  team  members  shall  have  functional  knowledge  of,  and  shall 
have  completed  the  system  developer's  internals  course  for,  the  system  being 
evaluated.  At  least  one  team  member  shall  be  familiar  enough  with  the 
system  hardware  to  understand  the  maintenance  diagnostic  programs  and 
supporting  hardware  documentation.  At  least  two  team  members  shall  have 
previously  completed  a  security  test  on  another  system.  At  least  one  team 
member  shall  have  demonstrated  system  level  programming  competence  on 
the  system  under  test  to  a  level  of  complexity  equivalent  to  adding  a  device 
driver  to  the  system. 

10.3.2  Testing 

The  team  shall  have  "hands-on"  involvement  in  an  independent  run  of  the  test 
package  used  by  the  system  developer  to  test  security-relevant  hardware  and 
software.  The  team  shall  independently  design  and  implement  at  least  twenty- 
five  system-specific  tests  in  an  attempt  to  circumvent  the  security  mechanisms 
of  the  system.  The  elapsed  time  devoted  to  testing  shall  be  at  least  three 
months  and  need  not  exceed  six  months.  There  shall  be  no  fewer  than  fifty 
hands-on  hours  per  team  member  spent  carrying  out  system  developer-defined 
tests  and  test  team-defined  tests. 


Commercial  Product  Evaluation  Process 
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Commercial  Product  Evaluation  Process 


"Department  of  Defense  Trusted  Computer  System  Evaluation  Criteria"  forms  the  basis 
upon  which  the  Computer  Security  Center  will  carry  out  the  commercial  computer  security 
evaluation  process.  This  process  is  focused  on  commercially  produced  and  supported 
general-purpose  operating  system  products  that  meet  the  needs  of  government  departments 
and  agencies.  The  formal  evaluation  is  aimed  at  "off-the-shelf"  commercially  supported 
products  and  is  completely  divorced  from  any  consideration  of  overall  system  performance, 
potential  applications,  or  particular  processing  environments.  The  evaluation  provides  a 
key  input  to  a  computer  system  security  approval/accreditation.  However,  it  does  not 
constitute  a  complete  computer  system  security  evaluation.  A  complete  study  (e.g.,  as  in 
reference  [18])  must  consider  additional  factors  dealing  with  the  system  in  its  unique 
environment,  such  as  it's  proposed  security  mode  of  operation,  specific  users,  applications, 
data  sensitivity,  physical  and  personnel  security,  administrative  and  procedural  security, 
TEMPEST,  and  communications  security. 

The  product  evaluation  process  carried  out  by  the  Computer  Security  Center  has  three 
distinct  elements: 

*  Preliminary  Product  Evaluation  -  An  informal  dialogue  between  a  vendor  and  the 
Center  in  which  technical  information  is  exchanged  to  create  a  common 
understanding  of  the  vendor's  product,  the  criteria,  and  the  rating  that  may  be 
expected  to  result  from  a  formal  product  evaluation. 

*  Formal  Product  Evaluation  -  A  formal  evaluation,  by  the  Center,  of  a  product  that 
is  available  to  the  DoD,  and  that  results  in  that  product  and  its  assigned  rating 
being  placed  on  the  Evaluated  Products  List. 

*  Evaluated  Products  List  -  A  list  of  products  that  have  been  subjected  to  formal 
product  evaluation  and  their  assigned  ratings. 


Preliminary  Product  Evaluation 

Since  it  is  generally  very  difficult  to  add  effective  security  measures  late  in  a  product's  life 
cycle,  the  Center  is  interested  in  working  with  system  vendors  in  the  early  stages  of  product 
design.  A  preliminary  product  evaluation  allows  the  Center  to  consult  with  computer 
vendors  on  computer  security  issues  found  in  products  that  have  not  yet  been  formally 
announced. 

A  preliminary  evaluation  is  typically  initiated  by  computer  system  vendors  who  are  planning 
new  computer  products  that  feature  security  or  major  security-related  upgrades  to  existing 
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products.  After  an  initial  meeting  between  the  vendor  and  the  Center,  appropriate 
non-disclosure  agreements  are  executed  that  require  the  Center  to  maintain  the 
confidentiality  of  any  proprietary  information  disclosed  to  it.  Technical  exchange  meetings 
follow  in  which  the  vendor  provides  details  about  the  proposed  product  (particularly  its 
internal  designs  and  goals)  and  the  Center  provides  expert  feedback  to  the  vendor  on 
potential  computer  security  strengths  and  weaknesses  of  the  vendor's  design  choices,  as  well 
as  relevant  interpretation  of  the  criteria.  The  preliminary  evaluation  is  typically  terminated 
when  the  product  is  completed  and  ready  for  field  release  by  the  vendor.  Upon 
termination,  the  Center  prepares  a  wrap-up  report  for  the  vendor  and  for  internal 
distribution  within  the  Center.  Those  reports  containing  proprietary  information  are  not 
available  to  the  public. 

During  preliminary  evaluation,  the  vendor  is  under  no  obligation  to  actually  complete  or 
market  the  potential  product.  The  Center  is,  likewise,  not  committed  to  conduct  a  formal 
product  evaluation.  A  preliminary  evaluation  may  be  terminated  by  either  the  Center  or  the 
vendor  when  one  notifies  the  other,  in  writing,  that  it  is  no  longer  advantageous  to  continue 
the  evaluation. 


Formal  Product  Evaluation 

The  formal  product  evaluation  provides  a  key  input  to  certification  of  a  computer  system 
for  use  in  National  Security  Establishment  applications  and  is  the  sole  basis  for  a  product 
being  placed  on  the  Evaluated  Products  List. 

A  formal  product  evaluation  begins  with  a  request  by  a  vendor  for  the  Center  to  evaluate  a 
product  for  which  the  product  itself  and  accompanying  documentation  needed  to  meet  the 
requirements  defined  by  this  publication  are  complete.  Non-disclosure  agreements  are 
executed  and  a  formal  product  evaluation  team  is  formed  by  the  Center.  An  initial  meeting 
is  then  held  with  the  vendor  to  work  out  the  schedule  for  the  formal  evaluation.  Since 
testing  of  the  implemented  product  forms  an  important  part  of  the  evaluation  process, 
access  by  the  evaluation  team  to  a  working  version  of  the  system  is  negotiated  with  the 
vendor.  Additional  support  required  from  the  vendor  includes  complete  design 
documentation,  source  code,  and  access  to  vendor  personnel  who  can  answer  detailed 
questions  about  specific  portions  of  the  product.  The  evaluation  team  tests  the  product 
against  each  requirement,  making  any  necessary  interpretations  of  the  criteria  with  respect 
to  the  product  being  evaluated. 

The  evaluation  team  writes  a  two-part  final  report  on  their  findings  about  the  system.  The 
first  part  is  publicly  available  (containing  no  proprietary  information)  and  contains  the 
overall  class  rating  assigned  to  the  system  and  the  details  of  the  evaluation  team's  findings 
when  comparing  the  product  against  the  evaluation  criteria.  The  second  part  of  the 
evaluation  report  contains  vulnerability  analyses  and  other  detailed  information  supporting 
the  rating  decision.  Since  this  part  may  contain  proprietary  or  other  sensitive  information 
it  will  be  distributed  only  within  the  U.S.  Government  on  a  strict  need-to-know  and 
non-disclosure  basis,  and  to  the  vendor.  No  portion  of  the  evaluation  results  will  be 
withheld  from  the  vendor. 


Division  Summary 
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Summary  of  Evaluation  Criteria  Divisions 


The  divisions  of  systems  recognized  under  the  trusted  computer  system  evaluation  criteria 
are  as  follows.  Each  division  represents  a  major  improvement  in  the  overall  confidence  one 
can  place  in  the  system  to  protect  classified  and  other  sensitive  information. 


Division  (D):  Minimal  Protection 

This  division  contains  only  one  class.  It  is  reserved  for  those  systems  that  have  been 
evaluated  but  that  fail  to  meet  the  requirements  for  a  higher  evaluation  class. 


Division  (C):  Discretionary  Protection 

Classes  in  this  division  provide  for  discretionary  (need-to-know)  protection  and,  through  the 
inclusion  of  audit  capabilities,  for  accountability  of  subjects  and  the  actions  they  initiate. 


Division  (B):  Mandatory  Protection 

The  notion  of  a  TCB  that  preserves  the  integrity  of  sensitivity  labels  and  uses  them  to 
enforce  a  set  of  mandatory  access  control  rules  is  a  major  requirement  in  this  division. 
Systems  in  this  division  must  carry  the  sensitivity  labels  with  major  data  structures  in  the 
system.  The  system  developer  also  provides  the  security  policy  model  on  which  the  TCB  is 
based  and  furnishes  a  specification  of  the  TCB.  Evidence  must  be  provided  to  demonstrate 
that  the  reference  monitor  concept  has  been  implemented. 

Division  (A):  Verified  Protection 

This  division  is  characterized  by  the  use  of  formal  security  verification  methods  to  assure 
that  the  mandatory  and  discretionary  security  controls  employed  in  the  system  can 
effectively  protect  classified  or  other  sensitive  information  stored  or  processed  by  the 
system.  Extensive  documentation  is  required  to  demonstrate  that  the  TCB  meets  the 
security  requirements  in  all  aspects  of  design,  development  and  implementation. 


Class  Summary 
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Summary  of  Evaluation  Criteria  Classes 


The  classes  of  systems  recognized  under  the  trusted  computer  system  evaluation  criteria  are 
as  follows.  They  are  presented  in  the  order  of  increasing  desirablity  from  a  computer 
security  point  of  view. 

Class  (D):  Minimal  Protection 

This  class  is  reserved  for  those  systems  that  have  been  evaluated  but  that  fail  to  meet  the 
requirements  for  a  higher  evaluation  class. 


Class  (Cl):  Discretionary  Security  Protection 

The  Trusted  Computing  Base  (TCB)  of  a  class  (Cl)  system  nominally  satisfies  the 
discretionary  security  requirements  by  providing  separation  of  users  and  data.  It 
incorporates  some  form  of  credible  controls  capable  of  enforcing  access  limitations  on  an 
individual  basis,  i.e.,  ostensibly  suitable  for  allowing  users  to  be  able  to  protect  project  or 
private  information  and  to  keep  other  users  from  accidentally  reading  or  destroying  their 
data.  The  class  (Cl)  environment  is  expected  to  be  one  of  cooperating  users  processing  data 
at  the  same  level(s)  of  sensitivity. 


Class  (C2):  Controlled  Access  Protection 

Systems  in  this  class  enforce  a  more  finely  grained  discretionary  access  control  than  (Cl) 
systems,  making  users  individually  accountable  for  their  actions  through  login  procedures, 
auditing  of  security-relevant  events,  and  resource  isolation. 


Class  (B1):  Labeled  Security  Protection 

Class  (Bl)  systems  require  all  the  features  required  for  class  (C2).  In  addition,  an  informal 
statement  of  the  security  policy  model,  data  labeling,  and  mandatory  access  control  over 
named  subjects  and  objects  must  be  present.  The  capability  must  exist  for  accurately 
labeling  exported  information.  Any  flaws  identified  by  testing  must  be  removed. 
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Class  (B2):  Structured  Protection 

In  class  (B2)  systems,  the  TCB  is  based  on  a  clearly  defined  and  documented  formal  security 
policy  model  that  requires  the  discretionary  and  mandatory  access  control  enforcement 
found  in  class  (Bl)  systems  be  extended  to  all  subjects  and  objects  in  the  ADP  system.  In 
addition,  covert  channels  are  addressed.  The  TCB  must  be  carefully  structured  into 
protection-critical  and  non-protection-critical  elements.  The  TCB  interface  is  well-defined 
and  the  TCB  design  and  implementation  enable  it  to  be  subjected  to  more  thorough  testing 
and  more  complete  review.  Authentication  mechanisms  are  strengthened,  trusted  facility 
management  is  provided  in  the  form  of  support  for  system  administrator  and  operator 
functions,  and  stringent  configuration  management  controls  are  imposed.  The  system  is 
relatively  resistant  to  penetration. 


Class  (B3):  Security  Domains 

The  class  (B3)  TCB  must  satisfy  the  reference  monitor  requirements  that  it  mediate  all 
accesses  of  subjects  to  objects,  be  tamperproof,  and  be  small  enough  to  be  subjected  to 
analysis  and  tests.  To  this  end,  the  TCB  is  structured  to  exclude  code  not  essential  to 
security  policy  enforcement,  with  significant  system  engineering  during  TCB  design  and 
implementation  directed  toward  minimizing  its  complexity.  A  security  administrator  is 
supported,  audit  mechanisms  are  expanded  to  signal  security-relevant  events,  and  system 
recovery  procedures  are  required.  The  system  is  highly  resistant  to  penetration. 


Class  (Al):  Verified  Design 

Systems  in  class  (Al)  are  functionally  equivalent  to  those  in  class  (B3)  in  that  no  additional 
architectural  features  or  policy  requirements  are  added.  The  distinguishing  feature  of 
systems  in  this  class  is  the  analysis  derived  from  formal  design  specification  and  verification 
techniques  and  the  resulting  high  degree  of  assurance  that  the  TCB  is  correctly 
implemented.  This  assurance  is  developmental  in  nature,  starting  with  a  formal  model  of 
the  security  policy  and  a  formal  top-level  specification  (FTLS)  of  the  design.  In  keeping 
with  the  extensive  design  and  development  analysis  of  the  TCB  required  of  systems  in  class 
(Al),  more  stringent  configuration  management  is  required  and  procedures  are  established 
for  securely  distributing  the  system  to  sites.  A  system  security  administrator  is  supported. 


Requirement  Directory 


93 


APPENDIX  D 


Requirement  Directory 


This  appendix  lists  requirements  defined  in  "Department  of  Defense  Trusted  Computer 
System  Evaluation  Criteria"  alphabetically  rather  than  by  class.  It  is  provided  to  assist  in 
following  the  evolution  of  a  requirement  through  the  classes.  For  each  requirement,  three 
types  of  criteria  may  be  present.  Each  will  be  preceded  by  the  word:  NEW,  CHANGE,  or 
ADD  to  indicate  the  following: 

NEW:  Any  criteria  appearing  in  a  lower  class  are  superseded  by  the  criteria  that 
follow. 

CHANGE:  The  criteria  that  follow  have  appeared  in  a  lower  class  but  are  changed  for 
this  class.  Highlighting  is  used  to  indicate  the  specific  changes  to  previously 
stated  criteria. 

ADD:  The  criteria  that  follow  have  not  been  required  for  any  lower  class,  and  are 
added  in  this  class  to  the  previously  stated  criteria  for  this  requirement. 

Abbreviations  are  used  as  follows: 

NR:  (No  Requirement)  This  requirement  is  not  included  in  this  class. 

NAR:  (No  Additional  Requirements)  This  requirement  does  not  change  from  the 
previous  class. 

The  reader  is  referred  to  Part  I  of  this  document  when  placing  new  criteria  for  a 
requirement  into  the  complete  context  for  that  class. 

Figure  I  provides  a  pictorial  summary  of  the  evolution  of  requirements  through  the  classes. 
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Audit 

Cl:  NR. 

C2:  NEW:  The  TCB  shall  be  able  to  create,  maintain,  and  protect  from  modification  or 
unauthorized  access  or  destruction  an  audit  trail  of  accesses  to  the  objects  it  protects. 
The  audit  data  shall  be  protected  by  the  TCB  so  that  read  access  to  it  is  limited  to 
those  who  are  authorized  for  audit  data.  The  TCB  shall  be  able  to  record  the 
following  types  of  events:  use  of  identification  and  authentication  mechanisms, 
introduction  of  objects  into  a  user's  address  space  (e.g.,  file  open,  program  initiation), 
deletion  of  objects,  and  actions  taken  by  computer  operators  and  system 
administrators  and/or  system  security  officers.  For  each  recorded  event,  the  audit 
record  shall  identify:  date  and  time  of  the  event,  user,  type  of  event,  and  success  or 
failure  of  the  event.  For  identification/authentication  events  the  origin  of  request 
(e.g.,  terminal  ID)  shall  be  included  in  the  audit  record.  For  events  that  introduce  an 
object  into  a  user's  address  space  and  for  object  deletion  events  the  audit  record  shall 
include  the  name  of  the  object.  The  ADP  system  administrator  shall  be  able  to 
selectively  audit  the  actions  of  any  one  or  more  users  based  on  individual  identity. 

Bl:  CHANGE:  For  events  that  introduce  an  object  into  a  user's  address  space  and  for 
object  deletion  events  the  audit  record  shall  include  the  name  of  the  object  and  the 
object's  security  level.  The  ADP  system  administrator  shall  be  able  to  selectively 
audit  the  actions  of  any  one  or  more  users  based  on  individual  identity  and/or  object 
security  level. 

ADD:  The  TCB  shall  also  be  able  to  audit  any  override  of  human-readable  output 
markings. 

B2:  ADD:  The  TCB  shall  be  able  to  audit  the  identified  events  that  may  be  used  in  the 
exploitation  of  covert  storage  channels. 

B3:  ADD:  The  TCB  shall  contain  a  mechanism  that  is  able  to  monitor  the  occurrence  or 
accumulation  of  security  auditable  events  that  may  indicate  an  imminent  violation  of 
security  policy.  This  mechanism  shall  be  able  to  immediately  notify  the  security 
administrator  when  thresholds  are  exceeded. 

Al:  NAR. 


Configuration  Management 


Cl:  NR. 
C2:  NR. 
Bl:  NR. 


B2:  NEW:  During  development  and  maintenance  of  the  TCB,  a  configuration  management 
system  shall  be  in  place  that  maintains  control  of  changes  to  the  descriptive  top-level 
specification,  other  design  data,  implementation  documentation,  source  code,  the 
running  version  of  the  object  code,  and  test  fixtures  and  documentation.  The 
configuration  management  system  shall  assure  a  consistent  mapping  among  all 
documentation  and  code  associated  with  the  current  version  of  the  TCB.  Tools  shall 
be  provided  for  generation  of  a  new  version  of  the  TCB  from  source  code.  Also 
available  shall  be  tools  for  comparing  a  newly  generated  version  with  the  previous 
TCB  version  in  order  to  ascertain  that  only  the  intended  changes  have  been  made  in 
the  code  that  will  actually  be  used  as  the  new  version  of  the  TCB. 
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B3:  NAR. 

Al:  CHANGE:  During  the  entire  life-cycle,  i.e.,  during  the  design,  development,  and 
maintenance  of  the  TCB,  a  configuration  management  system  shall  be  in  place  for  all 
security-relevant  hardware,  firmware,  and  software  that  maintains  control  of  changes 
to  the  formal  model,  the  descriptive  and  formal  top-level  specifications,  other  design 
data,  implementation  documentation,  source  code,  the  running  version  of  the  object 
code,  and  test  fixtures  and  documentation.  Also  available  shall  be  tools,  maintained 
under  strict  configuration  control,  for  comparing  a  newly  generated  version  with  the 
previous  TCB  version  in  order  to  ascertain  that  only  the  intended  changes  have  been 
made  in  the  code  that  will  actually  be  used  as  the  new  version  of  the  TCB. 

ADD:  A  combination  of  technical,  physical,  and  procedural  safeguards  shall  be  used  to 
protect  from  unauthorized  modification  or  destruction  the  master  copy  or  copies  of  all 
material  used  to  generate  the  TCB. 


Covert  Channel  Analysis 

Cl:  NR. 

C2:  NR. 

Bl:  NR. 

B2:  NEW:  The  system  developer  shall  conduct  a  thorough  search  for  covert  storage 
channels  and  make  a  determination  (either  by  actual  measurement  or  by  engineering 
estimation)  of  the  maximum  bandwidth  of  each  identified  channel.  (See  the  Covert 
Channels  Guideline  section.) 

B3:  CHANGE:  The  system  developer  shall  conduct  a  thorough  search  for  covert  channels 
and  make  a  determination  (either  by  actual  measurement  or  by  engineering  estimation) 
of  the  maximum  bandwidth  of  each  identified  channel. 

Al:  ADD:  Formal  methods  shall  be  used  in  the  analysis. 


Design  Documentation 

Cl:  NEW:  Documentation  shall  be  available  that  provides  a  description  of  the 
manufacturer's  philosophy  of  protection  and  an  explanation  of  how  this  philosophy  is 
translated  into  the  TCB.  If  the  TCB  is  composed  of  distinct  modules,  the  interfaces 
between  these  modules  shall  be  described. 

C2:  NAR. 

Bl :  ADD:  An  informal  or  formal  description  of  the  security  policy  model  enforced  by  the 
TCB  shall  be  available  and  an  explanation  provided  to  show  that  it  is  sufficient  to 
enforce  the  security  policy.  The  specific  TCB  protection  mechanisms  shall  be 
identified  and  an  explanation  given  to  show  that  they  satisfy  the  model. 

B2:  CHANGE:  The  interfaces  between  the  TCB  modules  shall  be  described.  A  formal 
description  of  the  security  policy  model  enforced  by  the  TCB  shall  be  available  and 
proven  that  it  is  sufficient  to  enforce  the  security  policy. 

ADD:  The  descriptive  top-level  specification  (DTLS)  shall  be  shown  to  be  an  accurate 
description  of  the  TCB  interface.  Documentation  shall  describe  how  the  TCB 
implements  the  reference  monitor  concept  and  give  an  explanation  why  it  is 
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tamperproof,  cannot  be  bypassed,  and  is  correctly  implemented.  Documentation  shall 
describe  how  the  TCB  is  structured  to  facilitate  testing  and  to  enforce  least  privilege. 
This  documentation  shall  also  present  the  results  of  the  covert  channel  analysis  and 
the  tradeoffs  involved  in  restricting  the  channels.  All  auditable  events  that  may  be 
used  in  the  exploitation  of  known  covert  storage  channels  shall  be  identified.  The 
bandwidths  of  known  covert  storage  channels,  the  use  of  which  is  not  detectable  by 
the  auditing  mechanisms,  shall  be  provided.  (See  the  Covert  Channel  Guideline 
section.) 

B3:  ADD:  The  TCB  implementation  (i.e.,  in  hardware,  firmware,  and  software)  shall  be 
informally  shown  to  be  consistent  with  the  DTLS.  The  elements  of  the  DTLS  shall  be 
shown,  using  informal  techniques,  to  correspond  to  the  elements  of  the  TCB. 

Al:  CHANGE:  The  TCB  implementation  (i.e.,  in  hardware,  firmware,  and  software)  shall 
be  informally  shown  to  be  consistent  with  the  formal  top-level  specification  (FTLS). 
The  elements  of  the  FTLS  shall  be  shown,  using  informal  techniques,  to  correspond 
to  the  elements  of  the  TCB. 

ADD:  Hardware,  firmware,  and  software  mechanisms  not  dealt  with  in  the  FTLS  but 
strictly  internal  to  the  TCB  (e.g.,  mapping  registers,  direct  memory  access  I/O)  shall 
be  clearly  described. 


Design  Specification  and  Verification 

Cl:  NR. 

C2:  NR. 

Bl:  NEW:  An  informal  or  formal  model  of  the  security  policy  supported  by  the  TCB  shall 
be  maintained  that  is  shown  to  be  consistent  with  its  axioms. 

B2:  CHANGE:  A  formal  model  of  the  security  policy  supported  by  the  TCB  shall  be 
maintained  that  is  proven  consistent  with  its  axioms. 

ADD:  A  descriptive  top-level  specification  (DTLS)  of  the  TCB  shall  be  maintained  that 
completely  and  accurately  describes  the  TCB  in  terms  of  exceptions,  error  messages, 
and  effects.  It  shall  be  shown  to  be  an  accurate  description  of  the  TCB  interface. 

B3:  ADD:  A  convincing  argument  shall  be  given  that  the  DTLS  is  consistent  with  the 
model. 

Al:  CHANGE:  The  FTLS  shall  be  shown  to  be  an  accurate  description  of  the  TCB 
interface.  A  convincing  argument  shall  be  given  that  the  DTLS  is  consistent  with  the 
model  and  a  combination  of  formal  and  informal  techniques  shall  be  used  to  show 
that  the  FTLS  is  consistent  with  the  model. 

ADD:  A  formal  top-level  specification  (FTLS)  of  the  TCB  shall  be  maintained  that 
accurately  describes  the  TCB  in  terms  of  exceptions,  error  messages,  and  effects.  The 
DTLS  and  FTLS  shall  include  those  components  of  the  TCB  that  are  implemented  as 
hardware  and/or  firmware  if  their  properties  are  visible  at  the  TCB  interface.  This 
verification  evidence  shall  be  consistent  with  that  provided  within  the  state-of-the-art 
of  the  particular  Computer  Security  Center-endorsed  formal  specification  and 
verification  system  used.  Manual  or  other  mapping  of  the  FTLS  to  the  TCB  source 
code  shall  be  performed  to  provide  evidence  of  correct  implementation. 
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Device  Labels 

Cl:  NR. 

C2:  NR. 

Bl:  NR. 

B2:  NEW:  The  TCB  shall  support  the  assignment  of  minimum  and  maximum  security  levels 
to  all  attached  physical  devices.  These  security  levels  shall  be  used  by  the  TCB  to 
enforce  constraints  imposed  by  the  physical  environments  in  which  the  devices  are 
located. 

B3:  NAR. 

Al:  NAR. 

Discretionary  Access  Control 

Cl:  NEW:  The  TCB  shall  define  and  control  access  between  named  users  and  named 
objects  (e.g.,  files  and  programs)  in  the  ADP  system.  The  enforcement  mechanism 
(e.g.,  self/group/public  controls,  access  control  lists)  shall  allow  users  to  specify  and 
control  sharing  of  those  objects  by  named  individuals  or  defined  groups  or  both. 

C2:  CHANGE:  The  enforcement  mechanism  (e.g.,  self/group/public  controls,  access  control 
lists)  shall  allow  users  to  specify  and  control  sharing  of  those  objects  by  named 
individuals,  or  defined  groups  of  individuals,  or  by  both. 

ADD:  The  discretionary  access  control  mechanism  shall,  either  by  explicit  user  action 
or  by  default,  provide  that  objects  are  protected  from  unauthorized  access.  These 
access  controls  shall  be  capable  of  including  or  excluding  access  to  the  granularity  of  a 
single  user.  Access  permission  to  an  object  by  users  not  already  possessing  access 
permission  shall  only  be  assigned  by  authorized  users. 

Bl:  NAR. 

B2:  NAR. 

B3:  CHANGE:  The  enforcement  mechanism  (e.g.,  access  control  lists)  shall  allow  users  to 
specify  and  control  sharing  of  those  objects.  These  access  controls  shall  be  capable  of 

specifying,  for  each  named  object,  a  list  of  named  individuals  and  a  list  of  groups 
of  named  individuals  with  their  respective  modes  of  access  to  that  object. 

ADD:  Furthermore,  for  each  such  named  object,  it  shall  be  possible  to  specify  a  list 
of  named  individuals  and  a  list  of  groups  of  named  individuals  for  which  no  access  to 
the  object  is  to  be  given. 

Al:  NAR. 

Exportation  of  Labeled  Information 

Cl:  NR. 

C2:  NR. 

Bl :  NEW:  The  TCB  shall  designate  each  communication  channel  and  I/O  device  as  either 
single-level  or  multilevel.  Any  change  in  this  designation  shall  be  done  manually  and 
shall  be  auditable  by  the  TCB.  The  TCB  shall  maintain  and  be  able  to  audit  any 


98 


Requirement  Directory 


change  in  the  current  security  level  associated  with  a  single-level  communication 
channel  or  I/O  device. 

B2:  NAR. 

B3:  NAR. 

Al:  NAR. 

Exportation  to  Multilevel  Devices 

Cl:  NR. 

C2:  NR. 

Bl :  NEW:  When  the  TCB  exports  an  object  to  a  multilevel  I/O  device,  the  sensitivity  label 
associated  with  that  object  shall  also  be  exported  and  shall  reside  on  the  same  physical 
medium  as  the  exported  information  and  shall  be  in  the  same  form  (i.e.,  machine- 
readable  or  human-readable  form).  When  the  TCB  exports  or  imports  an  object  over 
a  multilevel  communication  channel,  the  protocol  used  on  that  channel  shall  provide 
for  the  unambiguous  pairing  between  the  sensitivity  labels  and  the  associated 
information  that  is  sent  or  received. 

B2:  NAR. 

B3:  NAR. 

Al:  NAR. 

Exportation  to  Single-Level  Devices 

Cl:  NR. 

C2:  NR. 

Bl:  NEW:  Single-level  I/O  devices  and  single-level  communication  channels  are  not 
required  to  maintain  the  sensitivity  labels  of  the  information  they  process.  However, 
the  TCB  shall  include  a  mechanism  by  which  the  TCB  and  an  authorized  user  reliably 
communicate  to  designate  the  single  security  level  of  information  imported  or  exported 
via  single-level  communication  channels  or  I/O  devices. 

B2:  NAR. 

B3:  NAR. 

Al:  NAR. 

Identification  and  Authentication 

Cl:  NEW:  The  TCB  shall  require  users  to  identify  themselves  to  it  before  beginning  to 
perform  any  other  actions  that  the  TCB  is  expected  to  mediate.  Furthermore,  the 
TCB  shall  use  a  protected  mechanism  (e.g.,  passwords)  to  authenticate  the  user's 
identity.  The  TCB  shall  protect  authentication  data  so  that  it  cannot  be  accessed  by 
any  unauthorized  user. 

C2:  ADD:  The  TCB  shall  be  able  to  enforce  individual  accountability  by  providing  the 
capability  to  uniquely  identify  each  individual  ADP  system  user.  The  TCB  shall  also 
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provide  the  capability  of  associating  this  identity  with  all  auditable  actions  taken  by 
that  individual. 

Bl:  CHANGE:  Furthermore,  the  TCB  shall  maintain  authentication  data  that  includes 
information  for  verifying  the  identity  of  individual  users  (e.g.,  passwords)  as  well  as 
information  for  determining  the  clearance  and  authorizations  of  individual  users. 
This  data  shall  be  used  by  the  TCB  to  authenticate  the  user's  identity  and  to 
determine  the  security  level  and  authorizations  of  subjects  that  may  be  created  to 
act  on  behalf  of  the  individual  user. 

B2:  NAR. 

B3:  NAR. 

Al:  NAR. 

Label  Integrity 

Cl:  NR. 

C2:  NR. 

B 1 :  NEW:  Sensitivity  labels  shall  accurately  represent  security  levels  of  the  specific  subjects 
or  objects  with  which  they  are  associated.  When  exported  by  the  TCB,  sensitivity 
labels  shall  accurately  and  unambiguously  represent  the  internal  labels  and  shall  be 
associated  with  the  information  being  exported. 

B2:  NAR. 

B3:  NAR. 

Al:  NAR. 

Labeling  Human-Readable  Output 

Cl:  NR. 

C2:  NR. 

Bl :  NEW:  The  ADP  system  administrator  shall  be  able  to  specify  the  printable  label  names 
associated  with  exported  sensitivity  labels.  The  TCB  shall  mark  the  beginning  and  end 
of  all  human-readable,  paged,  hardcopy  output  (e.g.,  line  printer  output)  with  human- 
readable  sensitivity  labels  that  properly1  represent  the  sensitivity  of  the  output.  The 
TCB  shall,  by  default,  mark  the  top  and  bottom  of  each  page  of  human-readable, 
paged,  hardcopy  output  (e.g.,  line  printer  output)  with  human-readable  sensitivity 
labels  that  properly1  represent  the  overall  sensitivity  of  the  output  or  that  properly1 
represent  the  sensitivity  of  the  information  on  the  page.  The  TCB  shall,  by  default 
and  in  an  appropriate  manner,  mark  other  forms  of  human-readable  output  (e.g., 
maps,  graphics)  with  human-readable  sensitivity  labels  that  properly1  represent  the 
sensitivity  of  the  output.  Any  override  of  these  marking  defaults  shall  be  auditable  by 
the  TCB. 

B2:  NAR. 


1  The  hierarchical  classification  component  in  human-readable  sensitivity  labels  shall  be  equal  to  the  greatest 
hierarchical  classification  of  any  of  the  information  in  the  output  that  the  labels  refer  to;  the 
non-hierarchical  category  component  shall  include  all  of  the  non-hierarchical  categories  of  the  information 
in  the  output  the  labels  refer  to,  but  no  other  non-hierarchical  categories. 
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B3:  NAR. 
Al:  NAR. 


Labels 

Cl:  NR. 

C2:  NR. 

Bl:  NEW:  Sensitivity  labels  associated  with  each  subject  and  storage  object  under  its 
control  (e.g.,  process,  file,  segment,  device)  shall  be  maintained  by  the  TCB.  These 
labels  shall  be  used  as  the  basis  for  mandatory  access  control  decisions.  In  order  to 
import  non-labeled  data,  the  TCB  shall  request  and  receive  from  an  authorized  user 
the  security  level  of  the  data,  and  all  such  actions  shall  be  auditable  by  the  TCB. 

B2:  CHANGE:  Sensitivity  labels  associated  with  each  ADP  system  resource  (e.g.,  subject, 
storage  object)  that  is  directly  or  indirectly  accessible  by  subjects  external  to  the 
TCB  shall  be  maintained  by  the  TCB. 

B3:  NAR. 

Al:  NAR. 

Mandatory  Access  Control 

Cl:  NR. 

C2:  NR. 

Bl :  NEW:  The  TCB  shall  enforce  a  mandatory  access  control  policy  over  all  subjects  and 
storage  objects  under  its  control  (e.g.,  processes,  files,  segments,  devices).  These 
subjects  and  objects  shall  be  assigned  sensitivity  labels  that  are  a  combination  of 
hierarchical  classification  levels  and  non-hierarchical  categories,  and  the  labels  shall  be 
used  as  the  basis  for  mandatory  access  control  decisions.  The  TCB  shall  be  able  to 
support  two  or  more  such  security  levels.  (See  the  Mandatory  Access  Control 
guidelines.)  The  following  requirements  shall  hold  for  all  accesses  between  subjects 
and  objects  controlled  by  the  TCB:  A  subject  can  read  an  object  only  if  the 
hierarchical  classification  in  the  subject's  security  level  is  greater  than  or  equal  to  the 
hierarchical  classification  in  the  object's  security  level  and  the  non-hierarchical 
categories  in  the  subject's  security  level  include  all  the  non-hierarchical  categories  in 
the  object's  security  level.  A  subject  can  write  an  object  only  if  the  hierarchical 
classification  in  the  subject's  security  level  is  less  than  or  equal  to  the  hierarchical 
classification  in  the  object's  security  level  and  all  the  non-hierarchical  categories  in  the 
subject's  security  level  are  included  in  the  non-hierarchical  categories  in  the  object's 
security  level. 

B2:  CHANGE:  The  TCB  shall  enforce  a  mandatory  access  control  policy  over  all  resources 
(i.e.,  subjects,  storage  objects,  and  I/O  devices)  that  are  directly  or  indirectly 
accessible  by  subjects  external  to  the  TCB.  The  following  requirements  shall  hold 
for  all  accesses  between  all  subjects  external  to  the  TCB  and  all  objects  directly  or 
indirectly  accessible  by  these  subjects: 

B3:  NAR. 

Al:  NAR. 


Requirement  Directory 


101 


Object  Reuse 

Cl:  NR. 

C2:  NEW:  When  a  storage  object  is  initially  assigned,  allocated,  or  reallocated  to  a  subject 
from  the  TCB's  pool  of  unused  storage  objects,  the  TCB  shall  assure  that  the  object 
contains  no  data  for  which  the  subject  is  not  authorized. 

Bl:  NAR. 

B2:  NAR. 

B3:  NAR. 

Al:  NAR. 

Security  Features  User's  Guide 

C I :  NEW:  A  single  summary,  chapter,  or  manual  in  user  documentation  shall  describe  the 
protection  mechanisms  provided  by  the  TCB,  guidelines  on  their  use,  and  how  they 
interact  with  one  another. 

C2:  NAR. 

Bl:  NAR. 

B2:  NAR. 

B3:  NAR. 

Al:  NAR. 

Security  Testing 

C 1 :  NEW:  The  security  mechanisms  of  the  ADP  system  shall  be  tested  and  found  to  work 
as  claimed  in  the  system  documentation.  Testing  shall  be  done  to  assure  that  there  are 
no  obvious  ways  for  an  unauthorized  user  to  bypass  or  otherwise  defeat  the  security 
protection  mechanisms  of  the  TCB.  (See  the  Security  Testing  guidelines.) 

C2:  ADD:  Testing  shall  also  include  a  search  for  obvious  flaws  that  would  allow  violation 
of  resource  isolation,  or  that  would  permit  unauthorized  access  to  the  audit  or 
authentication  data. 

Bl :  NEW:  The  security  mechanisms  of  the  ADP  system  shall  be  tested  and  found  to  work 
as  claimed  in  the  system  documentation.  A  team  of  individuals  who  thoroughly 
understand  the  specific  implementation  of  the  TCB  shall  subject  its  design 
documentation,  source  code,  and  object  code  to  thorough  analysis  and  testing.  Their 
objectives  shall  be:  to  uncover  all  design  and  implementation  flaws  that  would  permit 
a  subject  external  to  the  TCB  to  read,  change,  or  delete  data  normally  denied  under 
the  mandatory  or  discretionary  security  policy  enforced  by  the  TCB;  as  well  as  to 
assure  that  no  subject  (without  authorization  to  do  so)  is  able  to  cause  the  TCB  to 
enter  a  state  such  that  it  is  unable  to  respond  to  communications  initiated  by  other 
users.  All  discovered  flaws  shall  be  removed  or  neutralized  and  the  TCB  retested  to 
demonstrate  that  they  have  been  eliminated  and  that  new  flaws  have  not  been 
introduced.  (See  the  Security  Testing  Guidelines.) 

B2:  CHANGE:  All  discovered  flaws  shall  be  corrected  and  the  TCB  retested  to  demonstrate 
that  they  have  been  eliminated  and  that  new  flaws  have  not  been  introduced. 
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ADD:  The  TCB  shall  be  found  relatively  resistant  to  penetration.  Testing  shall 
demonstrate  that  the  TCB  implementation  is  consistent  with  the  descriptive  top-level 
specification. 

B3:  CHANGE:  The  TCB  shall  be  found  resistant  to  penetration. 

ADD:  No  design  flaws  and  no  more  than  a  few  correctable  implementation  flaws  may 
be  found  during  testing  and  there  shall  be  reasonable  confidence  that  few  remain. 

At:  CHANGE:  Testing  shall  demonstrate  that  the  TCB  implementation  is  consistent  with 
the  formal  top-level  specification. 

ADD:  Manual  or  other  mapping  of  the  FTLS  to  the  source  code  may  form  a  basis  for 
penetration  testing. 


Subject  Sensitivity  Labels 

Cl:  NR. 

C2:  NR. 

Bl:  NR. 

B2:  NEW:  The  TCB  shall  immediately  notify  a  terminal  user  of  each  change  in  the  security 
level  associated  with  that  user  during  an  interactive  session.  A  terminal  user  shall  be 
able  to  query  the  TCB  as  desired  for  a  display  of  the  subject's  complete  sensitivity 
label. 

B3:  NAR. 

Al:  NAR. 


System  Architecture 

Cl :  NEW:  The  TCB  shall  maintain  a  domain  for  its  own  execution  that  protects  it  from 
external  interference  or  tampering  (e.g.,  by  modification  of  its  code  or  data 
structures).  Resources  controlled  by  the  TCB  may  be  a  defined  subset  of  the  subjects 
and  objects  in  the  ADP  system. 

C2:  ADD:  The  TCB  shall  isolate  the  resources  to  be  protected  so  that  they  are  subject  to 
the  access  control  and  auditing  requirements. 

Bl:  ADD:  The  TCB  shall  maintain  process  isolation  through  the  provision  of  distinct 
address  spaces  under  its  control. 

B2:  NEW:  The  TCB  shall  maintain  a  domain  for  its  own  execution  that  protects  it  from 
external  interference  or  tampering  (e.g.,  by  modification  of  its  code  or  data 
structures).  The  TCB  shall  maintain  process  isolation  through  the  provision  of 
distinct  address  spaces  under  its  control.  The  TCB  shall  be  internally  structured  into 
well-defined  largely  independent  modules.  It  shall  make  effective  use  of  available 
hardware  to  separate  those  elements  that  are  protection-critical  from  those  that  are 
not.  The  TCB  modules  shall  be  designed  such  that  the  principle  of  least  privilege  is 
enforced.  Features  in  hardware,  such  as  segmentation,  shall  be  used  to  support 
logically  distinct  storage  objects  with  separate  attributes  (namely:  readable,  writeable). 
The  user  interface  to  the  TCB  shall  be  completely  defined  and  all  elements  of  the  TCB 
identified. 
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B3:  ADD:  The  TCB  shall  be  designed  and  structured  to  use  a  complete,  conceptually 
simple  protection  mechanism  with  precisely  defined  semantics.  This  mechanism  shall 
play  a  central  role  in  enforcing  the  internal  structuring  of  the  TCB  and  the  system. 
The  TCB  shall  incorporate  significant  use  of  layering,  abstraction  and  data  hiding. 
Significant  system  engineering  shall  be  directed  toward  minimizing  the  complexity  of 
the  TCB  and  excluding  from  the  TCB  modules  that  are  not  protection-critical. 

Al:  NAR. 

System  Integrity 

Cl:  NEW:  Hardware  and/or  software  features  shall  be  provided  that  can  be  used  to 
periodically  validate  the  correct  operation  of  the  on-site  hardware  and  firmware 
elements  of  the  TCB. 

C2:  NAR. 

Bl:  NAR. 

B2:  NAR. 

B3:  NAR. 

Al:  NAR. 

Test  Documentation 

C 1 :  NEW:  The  system  developer  shall  provide  to  the  evaluators  a  document  that  describes 
the  test  plan  and  results  of  the  security  mechanisms'  functional  testing. 

C2:  NAR. 

Bl:  NAR. 

B2:  ADD:  It  shall  include  results  of  testing  the  effectiveness  of  the  methods  used  to  reduce 
covert  channel  bandwidths. 

B3:  NAR. 

Al:  ADD:  The  results  of  the  mapping  between  the  formal  top-level  specification  and  the 
TCB  source  code  shall  be  given. 

Trusted  Distribution 

Cl:  NR. 

C2:  NR. 

Bl:  NR. 

B2:  NR. 

B3:  NR. 

A I :  NEW:  A  trusted  ADP  system  control  and  distribution  facility  shall  be  provided  for 
maintaining  the  integrity  of  the  mapping  between  the  master  data  describing  the 
current  version  of  the  TCB  and  the  on-site  master  copy  of  the  code  for  the  current 
version.  Procedures  (e.g.,  site  security  acceptance  testing)  shall  exist  for  assuring  that 
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the  TCB  software,  firmware,  and  hardware  updates  distributed  to  a  customer  are 
exactly  as  specified  by  the  master  copies. 


Trusted  Facility  Management 

Cl:  NR. 

C2:  NR. 

Bl:  NR. 

B2:  NEW:  The  TCB  shall  support  separate  operator  and  administrator  functions. 

B3:  ADD:  The  functions  performed  in  the  role  of  a  security  administrator  shall  be 
identified.  The  ADP  system  administrative  personnel  shall  only  be  able  to  perform 
security  administrator  functions  after  taking  a  distinct  auditable  action  to  assume  the 
security  administrator  role  on  the  ADP  system.  Non-security  functions  that  can  be 
performed  in  the  security  administration  role  shall  be  limited  strictly  to  those  essential 
to  performing  the  security  role  effectively. 

Al:  NAR. 


Trusted  Facility  Manual 

Cl:  NEW:  A  manual  addressed  to  the  ADP  system  administrator  shall  present  cautions 
about  functions  and  privileges  that  should  be  controlled  when  running  a  secure 
facility. 

C2:  ADD:  The  procedures  for  examining  and  maintaining  the  audit  files  as  well  as  the 
detailed  audit  record  structure  for  each  type  of  audit  event  shall  be  given. 

Bl:  ADD:  The  manual  shall  describe  the  operator  and  administrator  functions  related  to 
security,  to  include  changing  the  security  characteristics  of  a  user.  It  shall  provide 
guidelines  on  the  consistent  and  effective  use  of  the  protection  features  of  the  system, 
how  they  interact,  how  to  securely  generate  a  new  TCB,  and  facility  procedures, 
warnings,  and  privileges  that  need  to  be  controlled  in  order  to  operate  the  facility  in  a 
secure  manner. 

B2:  ADD:  The  TCB  modules  that  contain  the  reference  validation  mechanism  shall  be 
identified.  The  procedures  for  secure  generation  of  a  new  TCB  from  source  after 
modification  of  any  modules  in  the  TCB  shall  be  described. 

B3:  ADD:  It  shall  include  the  procedures  to  ensure  that  the  system  is  initially  started  in  a 
secure  manner.  Procedures  shall  also  be  included  to  resume  secure  system  operation 
after  any  lapse  in  system  operation. 


Al:  NAR. 
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Trusted  Path 

Cl:  NR. 

C2:  NR. 

Bl:  NR. 

B2:  NEW:  The  TCB  shall  support  a  trusted  communication  path  between  itself  and  user 
for  initial  login  and  authentication.  Communications  via  this  path  shall  be  initiated 
exclusively  by  a  user. 

B3:  CHANGE:  The  TCB  shall  support  a  trusted  communication  path  between  itself  and 

users  for  use  when  a  positive  TCB-to-user  connection  is  required  (e.g.,  login, 
change  subject  security  level).  Communications  via  this  trusted  path  shall  be 
activated  exclusively  by  a  user  or  the  TCB  and  shall  be  logically  isolated  and 
unmistakably  distinguishable  from  other  paths. 

Al:  NAR. 


Trusted  Recovery 

Cl:  NR. 

C2:  NR. 

Bl:  NR. 

B2:  NR. 

B3:  NEW:  Procedures  and/or  mechanisms  shall  be  provided  to  assure  that,  after  an  ADP 
system  failure  or  other  discontinuity,  recovery  without  a  protection  compromise  is 
obtained. 

Al:  NAR. 
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Access  -  A  specific  type  of  interaction  between  a  subject  and  an  object  that  results  in  the 
flow  of  information  from  one  to  the  other. 

Approval/Accreditation  -  The  official  authorization  that  is  granted  to  an  A  DP  system  to 
process  sensitive  information  in  its  operational  environment,  based  upon 
comprehensive  security  evaluation  of  the  system's  hardware,  firmware,  and  software 
security  design,  configuration,  and  implementation  and  of  the  other  system 
procedural,  administrative,  physical,  TEMPEST,  personnel,  and  communications 
security  controls. 

Audit  Trail  -  A  set  of  records  that  collectively  provide  documentary  evidence  of  processing 
used  to  aid  in  tracing  from  original  transactions  forward  to  related  records  and 
reports,  and/or  backwards  from  records  and  reports  to  their  component  source 
transactions. 

Authenticate  -  To  establish  the  validity  of  a  claimed  identity. 

Automatic  Data  Processing  (ADP)  System  -  An  assembly  of  computer  hardware, 
firmware,  and  software  configured  for  the  purpose  of  classifying,  sorting,  calculating, 
computing,  summarizing,  transmitting  and  receiving,  storing,  and  retrieving  data  with 
a  minimum  of  human  intervention. 

Bandwidth  -  A  characteristic  of  a  communication  channel  that  is  the  amount  of  information 
that  can  be  passed  through  it  in  a  given  amount  of  time,  usually  expressed  in  bits  per 
second. 

Bell-La  Padula  Model  -  A  formal  state  transition  model  of  computer  security  policy  that 
describes  a  set  of  access  control  rules.  In  this  formal  model,  the  entities  in  a 
computer  system  are  divided  into  abstract  sets  of  subjects  and  objects.  The  notion  of 
a  secure  state  is  defined  and  it  is  proven  that  each  state  transition  preserves  security 
by  moving  from  secure  state  to  secure  state;  thus,  inductively  proving  that  the  system 
is  secure.  A  system  state  is  defined  to  be  "secure"  if  the  only  permitted  access  modes 
of  subjects  to  objects  are  in  accordance  with  a  specific  security  policy.  In  order  to 
determine  whether  or  not  a  specific  access  mode  is  allowed,  the  clearance  of  a  subject 
is  compared  to  the  classification  of  the  object  and  a  determination  is  made  as  to 
whether  the  subject  is  authorized  for  the  specific  access  mode.  The  clearance/ 
classification  scheme  is  expressed  in  terms  of  a  lattice.  See  also:  Lattice,  Simple 
Security  Property,  ‘-Property. 


110 


Glossary 


Certification  -  The  technical  evaluation  of  a  system's  security  features,  made  as  part  of  and 
in  support  of  the  approval/accreditation  process,  that  establishes  the  extent  to  which 
a  particular  computer  system's  design  and  implementation  meet  a  set  of  specified 
security  requirements. 

Channel  -  An  information  transfer  path  within  a  system.  May  also  refer  to  the  mechanism 
by  which  the  path  is  effected. 

Covert  Channel  -  A  communication  channel  that  allows  a  process  to  transfer  information  in 
a  manner  that  violates  the  system's  security  policy.  See  also:  Covert  Storage 
Channel,  Covert  Timing  Channel. 

Covert  Storage  Channel  -  A  covert  channel  that  involves  the  direct  or  indirect  writing  of  a 
storage  location  by  one  process  and  the  direct  or  indirect  reading  of  the  storage 
location  by  another  process.  Covert  storage  channels  typically  involve  a  finite 
resource  (e.g.,  sectors  on  a  disk)  that  is  shared  by  two  subjects  at  different  security 
levels. 

Covert  Timing  Channel  -  A  covert  channel  in  which  one  process  signals  information  to 
another  by  modulating  its  own  use  of  system  resources  (e.g.,  CPU  time)  in  such  a 
way  that  this  manipulation  affects  the  real  response  time  observed  by  the  second 
process. 

Data  -  Information  with  a  specific  physical  representation. 

Data  Integrity  -  The  state  that  exists  when  computerized  data  is  the  same  as  that  in  the 
source  documents  and  has  not  been  exposed  to  accidental  or  malicious  alteration  or 
destruction. 


Descriptive  Top-Level  Specification  (DTLS)  -  A  top-level  specification  that  is  written  in  a 
natural  language  (e.g.,  English),  an  informal  program  design  notation,  or  a 
combination  of  the  two. 

Discretionary  Access  Control  -  A  means  of  restricting  access  to  objects  based  on  the 
identity  of  subjects  and/or  groups  to  which  they  belong.  The  controls  are 
discretionary  in  the  sense  that  a  subject  with  a  certain  access  permission  is  capable  of 
passing  that  permission  (perhaps  indirectly)  on  to  any  other  subject. 

Domain  -  The  set  of  objects  that  a  subject  has  the  ability  to  access. 

Dominate  -  Security  level  S(  is  said  to  dominate  security  level  S2  if  the  hierarchical 
classification  of  S|  is  greater  than  or  equal  to  that  of  S2  and  the  non-hierarchical 
categories  of  S,  include  all  those  of  S2  as  a  subset. 

Exploitable  Channel  -  Any  channel  that  is  useable  or  detectable  by  subjects  external  to  the 
Trusted  Computing  Base. 

Flaw  Hypothesis  Methodology  -  A  system  analysis  and  penetration  technique  where 
specifications  and  documentation  for  the  system  are  analyzed  and  then  flaws  in  the 
system  are  hypothesized.  The  list  of  hypothesized  flaws  is  then  prioritized  on  the 
basis  of  the  estimated  probability  that  a  flaw  actually  exists  and,  assuming  a  flaw  does 
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exist,  on  the  ease  of  exploiting  it  and  on  the  extent  of  control  or  compromise  it 
would  provide.  The  prioritized  list  is  used  to  direct  the  actual  testing  of  the  system. 

Flaw  -  An  error  of  commission,  omission,  or  oversight  in  a  system  that  allows  protection 
mechanisms  to  be  bypassed. 

Formal  Proof  -  A  complete  and  convincing  mathematical  argument,  presenting  the  full 
logical  justification  for  each  proof  step,  for  the  truth  of  a  theorem  or  set  of 
theorems.  The  formal  verification  process  uses  formal  proofs  to  show  the  truth  of 
certain  properties  of  formal  specification  and  for  showing  that  computer  programs 
satisfy  their  specifications. 

Formal  Security  Policy  Model  -  A  mathematically  precise  statement  of  a  security  policy. 
To  be  adequately  precise,  such  a  model  must  represent  the  initial  state  of  a  system, 
the  way  in  which  the  system  progresses  from  one  state  to  another,  and  a  definition  of 
a  "secure"  state  of  the  system.  To  be  acceptable  as  a  basis  for  a  TCB,  the  model 
must  be  supported  by  a  formal  proof  that  if  the  initial  state  of  the  system  satisfies  the 
definition  of  a  "secure"  state  and  if  all  assumptions  required  by  the  model  hold,  then 
all  future  states  of  the  system  will  be  secure.  Some  formal  modeling  techniques 
include:  state  transition  models,  temporal  logic  models,  denotational  semantics 
models,  algebraic  specification  models.  An  example  is  the  model  described  by  Bell 
and  LaPadula  in  reference  [2],  See  also:  Bell-LaPadula  Model,  Security  Policy 
Model. 

Formal  Top-Level  Specification  (FTLS)  -  A  Top-Level  Specification  that  is  written  in  a 
formal  mathematical  language  to  allow  theorems  showing  the  correspondence  of  the 
system  specification  to  its  formal  requirements  to  be  hypothesized  and  formally 
proven. 

Formal  Verification  -  The  process  of  using  formal  proofs  to  demonstrate  the  consistency 
(design  verification)  between  a  formal  specification  of  a  system  and  a  formal  security 
policy  model  or  (implementation  verification)  between  the  formal  specification  and  its 
program  implementation. 

Functional  Testing  -  The  portion  of  security  testing  in  which  the  advertised  features  of  a 
system  are  tested  for  correct  operation. 

General-Purpose  System  -  A  computer  system  that  is  designed  to  aid  in  solving  a  wide 
variety  of  problems. 

Lattice  -  A  partially  ordered  set  for  which  every  pair  of  elements  has  a  greatest  lower 
bound  and  a  least  upper  bound. 

Least  Privilege  -  This  principle  requires  that  each  subject  in  a  system  be  granted  the  most 
restrictive  set  of  privileges  (or  lowest  clearance)  needed  for  the  performance  of 
authorized  tasks.  The  application  of  this  principle  limits  the  damage  that  can  result 
from  accident,  error,  or  unauthorized  use. 

Mandatory  Access  Control  -  A  means  of  restricting  access  to  objects  based  on  the 
sensitivity  (as  represented  by  a  label)  of  the  information  contained  in  the  objects  and 
the  formal  authorization  (i.e.,  clearance)  of  subjects  to  access  information  of  such 
sensitivity. 
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Multilevel  Device  -  A  device  that  is  used  in  a  manner  that  permits  it  to  simultaneously 
process  data  of  two  or  more  security  levels  without  risk  of  compromise.  To 
accomplish  this,  sensitivity  labels  are  normally  stored  on  the  same  physical  medium 
and  in  the  same  form  (i.e.,  machine-readable  or  human-readable)  as  the  data  being 
processed. 

Multilevel  Secure  -  A  class  of  system  containing  information  with  different  sensitivities  that 
simultaneously  permits  access  by  users  with  different  security  clearances  and  needs- 
to-know,  but  prevents  users  from  obtaining  access  to  information  for  which  they  lack 
authorization. 

Object  -  A  passive  entity  that  contains  or  receives  information.  Access  to  an  object 
potentially  implies  access  to  the  information  it  contains.  Examples  of  objects  are: 
records,  blocks,  pages,  segments,  files,  directories,  directory  trees,  and  programs,  as 
well  as  bits,  bytes,  words,  fields,  processors,  video  displays,  keyboards,  clocks, 
printers,  network  nodes,  etc. 

Object  Reuse  -  The  reassignment  to  some  subject  of  a  medium  (e.g.,  page  frame,  disk 
sector,  magnetic  tape)  that  contained  one  or  more  objects.  To  be  securely  reassigned, 
such  media  must  contain  no  residual  data  from  the  previously  contained  object(s). 

Output  -  Information  that  has  been  exported  by  a  TCB. 

Password  -  A  private  character  string  that  is  used  to  authenticate  an  identity. 

Penetration  Testing  -  The  portion  of  security  testing  in  which  the  penetrators  attempt  to 
circumvent  the  security  features  of  a  system.  The  penetrators  may  be  assumed  to  use 
all  system  design  and  implementation  documentation,  which  may  include  listings  of 
system  source  code,  manuals,  and  circuit  diagrams.  The  penetrators  work  under  no 
constraints  other  than  those  that  would  be  applied  to  ordinary  users. 

Process  -  A  program  in  execution.  It  is  completely  characterized  by  a  single  current 
execution  point  (represented  by  the  machine  state)  and  address  space. 

Protection-Critical  Portions  of  the  TCB  -  Those  portions  of  the  TCB  whose  normal 
function  is  to  deal  with  the  control  of  access  between  subjects  and  objects. 

Protection  Philosophy  -  An  informal  description  of  the  overall  design  of  a  system  that 
delineates  each  of  the  protection  mechanisms  employed.  A  combination  (appropriate 
to  the  evaluation  class)  of  formal  and  informal  techniques  is  used  to  show  that  the 
mechanisms  are  adequate  to  enforce  the  security  policy. 

Read  -  A  fundamental  operation  that  results  only  in  the  flow  of  information  from  an  object 
to  a  subject. 

Read  Access  -  Permission  to  read  information. 

Reference  Monitor  Concept  -  An  access  control  concept  that  refers  to  an  abstract  machine 
that  mediates  all  accesses  to  objects  by  subjects. 

Resource  -  Anything  used  or  consumed  while  performing  a  function.  The  categories  of 
resources  are:  time,  information,  objects  (information  containers),  or  processors  (the 
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ability  to  use  information).  Specific  examples  are:  CPU  time;  terminal  connect  time; 
amount  of  directly-addressable  memory;  disk  space;  number  of  I/O  requests  per 
minute,  etc. 

Security  Kernel  -  The  hardware,  firmware,  and  software  elements  of  a  Trusted  Computing 
Base  that  implement  the  reference  monitor  concept.  It  must  mediate  all  accesses,  be 
protected  from  modification,  and  be  verifiable  as  correct. 

Security  Level  -  The  combination  of  a  hierarchical  classification  and  a  set  of 
non-hierarchical  categories  that  represents  the  sensitivity  of  information. 

Security  Policy  -  The  set  of  laws,  rules,  and  practices  that  regulate  how  an  organization 
manages,  protects,  and  distributes  sensitive  information. 

Security  Policy  Model  -  An  informal  presentation  of  a  formal  security  policy  model. 

Security  Testing  -  A  process  used  to  determine  that  the  security  features  of  a  system  are 
implemented  as  designed  and  that  they  are  adequate  for  a  proposed  application 
environment.  This  process  includes  hands-on  functional  testing,  penetration  testing, 
and  verification.  See  also:  Functional  Testing,  Penetration  Testing,  Verification. 

Sensitive  Information  -  Information  that,  as  determined  by  a  competent  authority,  must  be 
protected  because  its  unauthorized  disclosure,  alteration,  loss,  or  destruction  will  at 
least  cause  perceivable  damage  to  someone  or  something. 

Sensitivity  Label  -  A  piece  of  information  that  represents  the  security  level  of  an  object 
and  that  describes  the  sensitivity  (e.g.,  classification)  of  the  data  in  the  object. 
Sensitivity  labels  are  used  by  the  TCB  as  the  basis  for  mandatory  access  control 
decisions. 

Simple  Security  Property  -  A  Bell-LaPadula  security  model  rule  allowing  a  subject  read 
access  to  an  object  only  if  the  security  level  of  the  subject  dominates  the  security 
level  of  the  object. 

Single-Level  Device  -  A  device  that  is  used  to  process  data  of  a  single  security  level  at  any 
one  time.  Since  the  device  need  not  be  trusted  to  separate  data  of  different  security 
levels,  sensitivity  labels  do  not  have  to  be  stored  with  the  data  being  processed. 

•-Property  (Star  Property)  -  A  Bell-LaPadula' security  model  rule  allowing  a  subject  write 
access  to  an  object  only  if  the  security  level  of  the  subject  is  dominated  by  the 
security  level  of  the  object.  Also  known  as  the  Confinement  Property. 

Storage  Object  -  An  object  that  supports  both  read  and  write  accesses. 

Subject  -  An  active  entity,  generally  in  the  form  of  a  person,  process,  or  device  that  causes 
information  to  flow  among  objects  or  changes  the  system  state.  Technically,  a 
process/domain  pair. 

Subject  Security  Level  -  A  subject's  security  level  is  equal  to  the  security  level  of  the 
objects  to  which  it  has  both  read  and  write  access.  A  subject's  security  level  must 
always  be  dominated  by  the  clearance  of  the  user  the  subject  is  associated  with. 
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TEMPEST  -  The  study  and  control  of  spurious  electronic  signals  emitted  from  ADP 
equipment. 

Top-Level  Specification  (TLS)  -  A  non-procedural  description  of  system  behavior  at  the 
most  abstract  level.  Typically  a  functional  specification  that  omits  all  implementation 
details. 

Trap  Door  -  A  hidden  software  or  hardware  mechanism  that  permits  system  protection 
mechanisms  to  be  circumvented.  It  is  activated  in  some  non-apparent  manner  (e.g., 
special  "random"  key  sequence  at  a  terminal). 

Trojan  Horse  -  A  computer  program  with  an  apparently  or  actually  useful  function  that 
contains  additional  (hidden)  functions  that  surreptitiously  exploit  the  legitimate 
authorizations  of  the  invoking  process  to  the  detriment  of  security.  For  example, 
making  a  "blind  copy"  of  a  sensitive  file  for  the  creator  of  the  Trojan  Horse. 

Trusted  Computer  System  -  A  system  that  employs  sufficient  hardware  and  software 
integrity  measures  to  allow  its  use  for  processing  sensitive  information. 

Trusted  Computing  Base  (TCB)  -  The  totality  of  protection  mechanisms  within  a  computer 
system  --  including  hardware,  firmware,  and  software  --  the  combination  of  which  is 
responsible  for  enforcing  a  security  policy.  It  creates  a  basic  protection  environment 
and  provides  additional  user  services  required  for  a  trusted  computer  system.  The 
ability  of  a  trusted  computing  base  to  correctly  enforce  a  security  policy  depends 
solely  on  the  mechanisms  within  the  TCB  and  on  the  correct  input  by  system 
administrative  personnel  of  parameters  (e.g.,  a  user's  clearance)  related  to  the 
security  policy. 


Trusted  Path  -  A  mechanism  by  which  a  person  at  a  terminal  can  communicate  directly 
with  the  Trusted  Computing  Base.  This  mechanism  can  only  be  activated  by  the 
person  or  the  Trusted  Computing  Base  and  cannot  be  imitated  by  untrusted  software. 

Trusted  Software  -  The  software  portion  of  a  Trusted  Computing  Base. 

User  -  Any  person  who  interacts  directly  with  a  computer  system. 

Verification  -  The  process  of  comparing  two  levels  of  system  specification  for  proper 
correspondence  (e.g.,  security  policy  model  with  top-level  specification,  TLS  with 
source  code,  or  source  code  with  object  code).  This  process  may  or  may  not  be 
automated. 

Write  -  A  fundamental  operation  that  results  only  in  the  flow  of  information  from  a  subject 
to  an  object. 

Write  Access  -  Permission  to  write  an  object. 
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